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B-ISDN ATM ADAPTATION LAYER (AAL) SPECIFICATION 

(Geneva, 1991; revised Helsinki, 1993) 



1 Introduction 

The ATM adaptation layer (AAL) enhances the service provided by the ATM layer to support functions required by the 
next hiXr laL The AAL performs functions required by the user, control and management planes and supports Je 
the ATM layer and the next higher layer. The functions performed in the AAL depend upon the higher 
layer requirements. 

The AAL supports multiple protocols to fit the needs of the different AAL service users. The service provided by the 
AAL to the higher layer and the functions performed are specified in this Recommendation. 

Details of the data unit naming convention used in this Recommendation can be found in Annex A. 

1.1 Scope of the Recommendation 

This Recommendation describes the interactions between the AAL and the next higher layer, and the AAL and the ATM 
layer, as well as AAL peer-to-peer operations. This Recommendation is based on the classificatoon and the AAL , 
functional organization described in Recommendation 1.362. 

Different combinations of SAR (segmentation and reassembly) sublayers and CS (convergence sublayer^ provide 
different service access points (SAPs) to the layer above the AAL. In some applications the SAR and/or CS may be 
empty. 

1.2 Information flow across the ATM-AAL boundary 

The AAL receives from the ATM layer the information in the form of a 48 octet ATM service data unit (A™-SDU). 
The AAL » the ATM layer information in the form of a 48 octet ATM SDU. See Recommendation 1.361 for the 

description of primitives provided by the ATM layer. 



2 AAL type 1 

2.1 Service provided by AAL type 1 
2.1.1 Definitions 

For the purpose of this Recommendation, the following definitions apply: 
The layer services provided by AAL type 1 to the AAL user are: 

- transfer of service data units with a constant source bit rate and the deUvery of them with the same bit 
rate; 

- transfer of timing information between source and destination; 

- transfer of structure information between source and destination; 

- indication of lost or errored information which is not recovered by AAL type 1, if needed. 
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2,1*2 Primitives 
* 2.1*2.1 General 

At the AAL-SAP, the following primitives will be used between the AAL type 1 and the AAL user: 
From an AAL user to the AAL, 

AAL-UNITDATA-REQUEST; 
From the AAL to an AAL user, 

AAL-UNITDATA-INDICATION. 

An AAL-UNITDATA-REQUEST primitive at the local AAL-SAP results in an AAL-UNITDATA-INDICATION 
primitive at its peer AAL- SAP. 

2.1*2.2 Definition of primitives 

2.1*2.2.1 AAL-UNITDATA-REQUEST 

AAL-UNITDATA-REQUEST (DATA [mandatory], 

STRUCTURE [optional]) 

The AAL-UNITDATA-REQUEST primitive requests the transfer of the AAL-SDU, i.e. contents of the DATA 
parameter, from the local AAL entity to its peer entity. The length of the AAL-SDU is constant and the time interval 
between two consecutive primitives is constant. These two constants are a function of the AAL service provided to 
the AAL user. 

2,1.2.2*2 AAL-UNITDATA-INDICATION 

AAL-UNITDATA-INDICATION (DATA (mandatory], 

STRUCTURE [optional], 
STATUS [optional]) 

An AAL user is notified by the AAL that the AAL-SDU, i.e. contents of the DATA parameter, from its peer are 
available. The length of the AAL-SDU should be constant and the time interval between two consecutive primitives 
should be constant. These two constants are a function of the AAL service provided to the AAL user. 

2.1.2.3 Definition of parameters 

2.1*2*3*1 STRUCTURE parameter 

The STRUCTURE parameter can be used when the user data stream to be transferred to the peer AAL entity is 
organized into groups of bits. The length of the structured block is fixed for each instance of the AAL service. The 
length is an integer multiple of 8 bits. An example of the use of this parameter is to support circuit mode bearer services 
of the 64 kbit/s based ISDN. The two values of the STRUCTURE parameter are: 

START; and 

CONTINUATION. 

The value START is used when the DATA is the first part of a structured block which can be composed of consecutive 
DATA. In other cases, the STRUCTURE parameter is set to CONTINUATION. The use of the STRUCTURE 
parameter depends on the type of AAL service provided. The use of this parameter is agreed prior to or at the connection 
establishment between the AAL user and the AAL. 

2.1.2.3.2 STATUS parameter 

The STATUS parameter identifies that the DATA is judged to be non-errored or errored. The STATUS parameter has 
two values: 

VALID; and 

INVALID. 

The INVALID status could also imply that the DATA is a dummy value. The use of the STATUS parameter and the 
choice of dummy value depend on the type of AAL service provided. The use of this parameter is agreed prior to or at 
the connection establishment between the AAL user and the AAL. 
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2.2 Interaction with the management and control planes 
2.2.1 Management plane 

The following indications may be passed from the user plane to the management plane: 

- errors in the transmission of user information; 

_ l0S t or misinserted cells (further study is required on whether it is necessary to distinguish between lost 
and misinserted cells for management purposes); 

_ ceUs with errored AAL protocol control information 1<^ A ^*>* " ***** * * 
this indication is necessary for layer services supported by this AAL type, 

- loss of timing and synchronization; 

- buffer under flow and overflow. 

2.2.2 Control plane 

For further study. 

2.3 Functions of AAL type 1 

u rf„™H in thP AAL tvoe 1 in order to enhance the ATM layer service: 
The following functions may be performed in the AAL type l in orucr 

a) segmentation and reassembly of user information; 

b) handling of cell delay variation; 

c) handling of cell pay load assembly delay; 

d) handling of lost and misinserted cells; 

e) source clock frequency recovery at the receiver, 

f) recovery of the source data structure at the receiver; 

g) monitoring of AAL-PCI for bit errors; 

h) handling of AAL-PCI bit errors; 

i) monitoring of user information field for bit errors and possible corrective action. 

Other functions are for further study. rpr f™- the 

NOTE-ForsomeAALuser^^ 
CS-PDU payload, carried in one or more cells, and transmitting the CRC results m the ruu , 

study is required. 

2.4 Segmentation and Reassembly (SAR) sublayer 

2.4.1 Functions of the SAR sublayer 

The SAR sublayer functions are performed on an ATM-SDU basis. 

a) Mapping between CS-PDU and SAR PDU 

b) Existence of CS function 

sar «p .. ^ »--*-—; S - .55?*SSS 3££ 

47 octet SAR-PDU payload, it receives this indication from the Lb ana convey f~ 
The use of this indication is optional. 
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c) Sequence numbering 

Associated with each SAR-PDU payload, the SAR sublayer receives a sequence number value from the 
CS. At the receiving end, it passes the sequence number value to the CS. The CS may use these sequence 
number values to detect lost or misinserted SAR-PDU payloads (corresponding to lost or misinserted 
ATM cells). 



d) Error protection 

The SAR sublayer protects the sequence number value and the CS indication against bit errors. It informs 
the receiving CS when the sequence number value and the CS indication are errored and cannot be 
corrected. 

NOTE - For certain applications such as speech, some SAR functions may not be needed. This item is for further 
study. 



2.4.2 SAR protocol 

The SAR-PDU header together with the 47 octets of the SAR-PDU payload comprises the 48 octet AIM-SDU 
(cell information field). The size and positions of the fields in the SAR-PDU are given in Figure 1. 



Cell header 


SN field 


SNP field 


SAR-PDU payload 




4 bits 


4bHs 


47 octets 



^ SAR-PDU header ^ 



SAR-PDU (48 octets) 



> 

T181132(V9(yd01 



FIGURE 1/1.363 
SAR-PDU format of AAL type 1 



2.4.2.1 Sequence number (SN) field 

The SN field is divided into two subfields as shown in Figure 2. The sequence count field carries the sequence count 
value provided by the convergence sublayer (CS). The CS1 bit carries the CS indication provided by the CS. The default 
value of the CSI bit is "0". 

The least significant bit of the sequence count value is right justified in the sequence count field. 



CSI bit 



Sequence court field (3 bits) 



SN field (4 bits) 



> 

Tl817600-92tt02 



FIGURE 2/1.363 
Sequence number (SN) field format 
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2.4.2 2 Sequence number protection (SNP) field 

The SNP field provides error detection and correction capabilities over the SAR-PDU header. The format of this field is 
given in Figure 3. A two step approach is used for the protection: 

1) The sequence number (SN) field is protected by a 3 bit CRC code. 

2) The resulting 7 bit codeword is protected by an even parity check bit. 



CRC field (3 bits) 



Even parity 
bit 



SNP field (4 bits) 



T181761O-92W03 



FIGURE 3/1.363 
SNP field format 



The receiver is capable of either single-bit error correction or multiple-bit error detection. 

a) Operations at transmitting end 

The transmitter computes the CRC value across the first 4 bits of the SAR-PDU header and inserts the 
result in the CRC field. 

The notation used to describe the CRC is based on the property of cyclic codes. The elements of an 
element codeword are thus the coefficients of a polynomial of order n - 1. In this application, these 
coefficients can have the value 0 or 1 and the polynomial operations are performed using modulo 2 
operations. For example a code vector such as 1011 can be represented by the polynomial 
?{x) = x 3 + x + 1. The polynomial representing the content of the SN field is generated using the first bit 
of the SN field as the coefficient of the highest order term. 

The CRC field consists of three bits. It shall contain the remainder of the division (modulo 2) by the 
generator polynomial jc 3 + jc + 1 of the product x 3 multiplied by the content of the SN field. 

After completing the above operations, the transmitter inserts the even parity bit. 

b) Operations at receiving end 

The receiver has two different modes of operation : correction mode and detection mode. These modes 
are related as shown in Figure 4. The default mode is the correction mode, which provides for single-bit 
error correction. At initialization, the receiver is set up in this default mode. 

The receiver examines each SAR-PDU header by checking the CRC bits and even parity bit. If a header 
error is detected, the action taken depends on the state of the receiver. In the "correction mode", only 
single-bit errors can be corrected and the receiver switches to "detection mode". In "detection mode", all 
SAR-PDU headers with detected errors are declared to have an invalid SN; however, when a SAR-PDU 
header is examined and found not to be in error, the receiver switches to "correction mode". 

Tables 1 and 2 give the detailed operations of the receiver in the "correction mode" and "detection mode", 
respectively. The operation is based on the combined validity of the CRC and parity check bit. 

The receiver conveys the sequence number count and the CS indication to the CS together with SN check 
status (valid or invalid). 
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No error detected 
(valid SN) 




No error detected (valid SN) 




Error detected 
(invalid SN) 




Single-bit error detected 
(valid SN after correction) 
Multi-bit error detected 
(invalid SN) 



T1 817620*2/004 



SN Sequence number 



FIGURE 4/1.363 



SNP: receiver modes of operation 



2 .5 Convergence sublayer (CS) 
2.5.1 Functions of the CS 

The CS may include the following functions. For performing some of these functions, the CS will need a clock. This • 
clock may be derived from the Sg or Tb interface. 

a) Handling of cell delay variation is performed at this sublayer for delivery of AAL-SDUs to an AAL user 
at a constant bit rate. 

b) Processing of sequence count may be performed at this sublayer. The sequence count value and its error 
check status provided by the SAR sublayer can be used by the CS to detect cell loss and misinsertion. 
Further handling of lost and misinserted cells is also performed in this sublayer. 

c) The CS can utilize the CS indication provided by the SAR sublayer to support CS functions for 
some AAL users. 

d) For AAL users requiring recovery of source clock frequency at the destination end, the AAL can provide 
a mechanism for a timing information transfer. 

e) For some AAL users, this sublayer provides the transfer of structure information between source 
and destination. 

f) For video and high quality audio signal transport, forward error correction may be performed to protect 
against bit errors. This may be combined with interleaving of AAL user bits (e.g. octet interleaving) 
to give more secure protection against errors. 

g) The CS may generate reports giving the status of end-to-end performance as deduced by the AAL. The 
performance measures in these reports could be based on: 



events of lost and misinserted cells; 



- buffer underflow and overflow; 



- bit error events. 



The following subclauses identify the functions of the CS for individual layer services of AAL type 1. 



6 
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TABLE 1/1.363 
Operations in correction mode 



CRC 
Syndrome 


Parity 


Action on current 
. SN + SNP 


Reaction for next 
SN + SNP 


Zero 


Wo violation 


No corrective action. 
Declare SN valid. 


Continue in correction mode 


Non-zero 


Violation 


Single bit correction based on syndrome. 
Declare SN valid. 


Switch to detection mode 


Zero 


Violation 


Correct parity bit 
Declare SN valid. 


Switch to detection mode 


Non-zero 


No violation 


No corrective action: multi-bit errors are 

uncorrectable. 

Declare SN invalid. 


Switch to detection mode 


SN Sequence n 
SNP Sequence n 


umber 

umber protection 





TABLE 2/1.363 
Operations in detection mode 



CRC 
Syndrome 


Parity 


Action on current 
SN + SNP 


Reaction for next 
SN + SNP 


Zero 


No violation 


No corrective action. 
Declare SN valid. 


Switch to correction mode 


Non-zero 


Violation 


No corrective action. 
Declare SN invalid. 


Continue in detection mode 


Zero 


Violation 


No corrective action. 
Declare SN invalid. 


Continue in detection mode 


Non-zero 


No violation 


No corrective action. 
Declare SN invalid. 


Continue in detection mode 


SN Sequence n 
SNP Sequence n 


umber 

umber protection 





2.5.1.1 Functions of the CS for circuit transport 

The following functions support both asynchronous and synchronous circuit transport . Asynchronous circuit transport 
wul transport of sfg^als from constant bit rate sources whose clocks are not Muency4ocked j . ^network 

clock' Examples » ReconLendation G.702 signals at 1544, 2048. 6312. 8448. 32 064. 44 736 and 34 MBkbfe 
Synchronous circuit transport will provide transport of signals from constant bit rate sources ( whose ctoto are 
fluency-locked to a network clock. Examples are signals at 64, 384. 1536 and 1920 kb.t/s as desenbed 
in Recommendation 1.23 i . 

NOTE - Another possible example of synchronous circuit transport is conveyance of SDH signals described in 
Recommendation G.709. 
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a) Handling ofAAL user information 

The length of the AAL-SDU is one bit, when asynchronous circuit transport utilizes the synchronous 
residual time stamp (SRTS) method described in 2.5.2.2.1. 

For those AAL users which require transfer of structured data, e.g. 8 kHz structured data for circuit mode 
bearer services of the 64 kbit/s based ISDN, the STRUCTURE parameter option of the primitives defined 
in 2. 1.2 will be used. The CS uses the structured data transfer (SDT) method described in 2.5.2.3. 

b) Handling of cell delay variation 

A buffer is used to support this function. The size of this buffer is dependent upon specifications currently 
understudy. 

In the event of buffer underflow, it may be necessary for the CS to maintain bit count integrity by 
inserting the appropriate number of dummy bits. In the event of buffer overflow, it may be necessary for 
the CS to maintain bit count integrity by dropping the appropriate number of bits. 

When Recommendation G.702 1.544 Mbit/s and 2.048 Mbit/s signals are being transported, the inserted 
dummy bits shall be all " 1 "s. 

c) Handling of lost and misinserted cells 

The sequence count values are further processed at this sublayer to detect lost and misinserted cells. 
Detected misinserted cells are discarded. The CS procedure to be used for sequence count processing is 
described in 2.5.2.1. 

In order to maintain the bit count integrity of the AAL user information, it may be necessary to f 
compensate for lost cells detected by buffer underflow and sequence count processing by inserting the 
appropriate number of dummy SAR-PDU pay loads. The content of this dummy SAR-PDU payload 
depends on the AAL service being provided. For example, this dummy SAR-PDU payload is all "l"s for 
Recommendation G.702 1.544 Mbit/s and 2.048 Mbit/s signals. 

d) Handling of timing relation 

This function is required for delivery of AAL-SDUs to an AAL user at a constant bit rate. 

The handling of timing relation for asynchronous circuit transport is referred to as source clock frequency 
recovery. Recovered source clock should have satisfactory jitter performance. For example, the jitter 
performance for Recommendation G.702 signals is specified in Recommendations G.823 and G.824, for 
which the CS procedure to be used (the SRTS method) is described in 2.5.2.2.1. 

2.5.1.2 Functions of the CS for video signal transport 

The following functions support transport of video signals for interactive and distributive services. 

a) Handling of AAL user information 

The length of the AAL-SDU is one octet, when utilizing the correction method described in 2.5.2.4.1 . 

For those AAL users which require transfer of structured data, the STRUCTURE parameter option of 
primitives defined in 2.1,2 will be used. The CS uses the SDT method described in 2.5.2.3. 

As an option, the STATUS parameter defined in 2.1.2 will be passed to the AAL user to facilitate further 
picture processing, e.g. error concealment 

b) Handling of cell delay variation 

A buffer is used to support this function. The size of this buffer is dependent upon specifications currently 
under study. 

In the event of buffer underflow, it may be necessary for the CS to maintain bit count integrity by 
inserting the appropriate number of dummy bits. In the event of buffer overflow, it may be necessary for 
the CS to maintain bit count integrity by dropping the appropriate number of bits. 



8 Recommendation 1363 (03/93) 

COPYRIGHT International Telecommunications Union/ ITU Telecommunications 



ITU-T ^MN*I.3b3 ^3 ■ ^2511 05836 



c) Handling of lost and misinserted cells 

The sequence count values are further processed at this sublayer to detect lost and misinserted cells. 
Detected misinserted cells are discarded. The CS procedure to be used for sequence count processing is 
described in 2.5.2.1. 

In order to maintain the bit count integrity of the AAL user information, it may be necessary to 
compensate for lost cells detected by buffer underflow and sequence count processing by inserting the 
appropriate number of dummy SAR-PDU payloads. The content of this dummy SAR-PDU payload 
depends on the AAL service being provided. 

Information in lost cells may be recovered by the mechanism described in e). 

d) Handling of timing relation 

This function is required for delivery of AAL-SDUs to an AAL user at a constant bit rate. 

Some AAL users may require source clock frequency recovery, e.g. recovery at the receiving end of 
camera clock frequency which is not locked to the network clock. The exact method is for further study. 

e) Correction of bit errors and lost cells 

This is an optional function provided for those AAL users requiring bit error and cell loss performance 
better than that provided by the ATM layer. Examples are unidirectional video services for contnbuuon 
and distribution. This function may be performed with the CS procedure described in 2.5.2.4.1. 

23.13 Functions of the CS for voice-band signal transport 

The following functions support transport of voice-band signals, e.g. 64 kbit/s A-law and u-law coded Recommen- 
dation G.711 signals, and 64 kbit/s Recommendation G.722 signals: 

a) Handling of AAL user information 
The length of the A AL-SDU is one octet 

b) Handling of cell delay variation 

A buffer is used to support this function. The size of this buffer is dependent upon specifications provided 
in Recommendation 1.356. 

c) Handling of lost and misinserted cells 

The detection of lost and misinserted cells, if needed, may be provided by processing the sequence count 
values. The monitoring of the buffer fill level can also provide an indication of lost and misinserted cells. 
Detected misinserted cells are discarded. 

Handling of lost cells and buffer underflow is for further study. 

NOTE - For transporting signals of speech and 3.1 kHz audio bearer services as specified in 64 kbit/s ISDN, the need for 
A/u-law conversion is identified. This conversion function is outside the scope of this Recommendauon. 

2.5.L4 Functions of the convergence sublayer for high quality audio signal transport 

The capabilities of AAL type 1 are in principle applicable for transfer of high quality audio signals. 
2.5.2 Convergence sublayer (CS) protocol 

The following subclauses describe CS procedures to be provided for implementing CS functions. The use of each 
procedure depends on the required CS functions and is given in 2.5.1.1 through to 2.5.1.4. 
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2*5*2.1 Sequence count operations 

2.5.2.1.1 Sequence count operations at the transmitting end 

At the transmitting end, the CS provides the SAR with a sequence count value and a CS indication associated with each 
SAR-PDU payload. The count, value starts with 0, is incremented sequentially and is numbered modulo 8. 

2.5.2.1.2 Sequence count operations at the receiving end 

At the receiving end, the CS receives from the SAR the following information associated with each SAR-PDU payload: 

- sequence count; 

- CS indication; 

- check status of the sequence count and CS indication. 

The use of sequence count values and CS indications will be specified on a service specific basis. See 2.4.2 for details 
about the check status processing. 

The CS processing at the receiving end may identify lost or misinserted SAR-PDU payloads. This will be useful for 
many CBR services. 

CS processing may identify the following conditions: 

- SAR-PDU payload sequence normal (i.e. in correct sequence); 

- SAR-PDU payload loss; 
SAR-PDU payload misinsertion. 

Processing of sequence count values may provide additional information to related entities within the CS, as required. 
Some examples are: 

location of lost SAR-PDU payload in the incoming SAR-PDU stream; 

number of consecutive SAR-PDU payloads lost; 

- identification of misinserted SAR-PDU payload 

NOTE - Processing of sequence count values may be subject to performance specifications. The performance 
specifications will be applied on a service specific basis. 

2.5.2.2 Source clock frequency recovery method 

2.5.2.2.1 Synchronous residual time stamp (SRTS) method 
a) General 

The synchronous residual time stamp (SRTS) method uses the residual time stamp (RTS) to measure and 
convey information about the frequency difference between a common reference clock derived from the 
network and a service clock. The same derived network clock is assumed to be available at both the 
transmitter and the receiver. If the common network reference clock is unavailable (e.g. when working 
between different networks which are not synchronized), then the asynchronous clock recovery method 
will be in a mode of operation associated with "Plesiochronous network operation" which is described 
in e). The SRTS method is capable of meeting the jitter specifications of the 2048 kbit/s hierarchy in 
Recommendation G.823 and the 1544 kbit/s hierarchy in Recommendation G.824. 

The following is a description of the SRTS method. The description uses the notation below: 

fs — service clock frequency; 

fn — network clock frequency, e.g. 155.52 MHz; 

fhx - derived network clock frequency, fhx=fn/x, where x is an integer to be 

defined later; 

N — period of RTS in cycles of the service clock of frequency fs; 
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T period of the RTS in seconds; 

M(Mnom, Mmax, Mmin) — number of fnx cycles within a (nominal, maximum, minimum) 

RTS period; 

Mq — largest integer smaller than or equal to M. 

The SRTS concept is illustrated in Figure 5. In a fixed duration T measured by N service clock cycles, the 
number of derived network clock cycles Mq is obtained at the transmitter. If Mq is transmitted to the 
receiver, the service clock of the source can be reconstructed by the receiver, since it has the necessary 
information: fnx, Mq and N. However, Mq is actually made up of a nominal part and a residual part. The 
nominal part Mnom corresponds to the nominal number of fhx cycles in T seconds and is fixed for the 
service. The residual part conveys the frequency difference information as well as the effect of the 
quantization and thus can vary. Since the nominal part is a constant, it can be assumed that the nominal 
part of Mq is available at the receiver. Only the residual part of Mq is transmitted to the receiver. 
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FIGURE 5./I.363 
The concept of synchronous residual time stamp (SRTS) 



A simple way of representing the residual part of Mq is by means of the RTS, whose generation is shown 
in Figure 6. Counter Ct is a P-bit counter which is continuously clocked by the denved network clock. 
The output of counter Ct is sampled every N service clock cycles. This P-bit sample is the residual time 
stamp. 

With a knowledge of the RTS and the nominal part of Mq at the receiver, Mq is completely specified. Mq 
is used to produce a reference timing signal for a phase-locked loop to obtain the service clock. 

b) Choice of parameter 

The minimum size of the RTS required to unambiguously represent the residual part of Mq is a function 
of N, the ratio fnx/fs, and the service clock tolerance, ± e. Let y be the difference between Mnom and the 
maximum or minimum value of M (denoted as Mmax, Mmin). The difference y is given by 



y = N* mx/fs* e. 
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FIGURE 6/1.363 
Generation of residual time stamp (RTS) 



In order that Mq can be unambiguously identified, the following conditions must be satisfied (see 
Figure 5): 

2(p-l)>M. 

where [y] denotes the smallest integer larger than or equal to y. 

The following parameter values are used for the asynchronous circuit transport of Recommen- 9 
dation G.702 signals: 

N = 3008 (total number of bits in eight SAR-PDU payloads), 
1 <rnx/fs^2, 
Tolerance = 200 * 10 ~* 
Size of RTS = 4 bits 

The introduction of any AAL convergence sublayer overhead into the SAR-PDU payload will reduce the 
amount of payload available for the transport of AAL user data. This will reduce the number of service 
clock cycles over which the RTS period is specified, since the RTS period is defined over a fixed number 
of SAR-PDU payloads. The RTS period parameter, N, can be adjusted to accommodate such cases. For 
example, if four octets of CS overhead are required from every eight SAR-PDU payloads, then N would 
be reduced from 3008 to 2976. However, the CS overhead has to be allocated so that the RTS period 
always remains a constant number of service clock cycles. Therefore, the CS overhead must reduce the 
user data transport capacity by a constant amount over the fixed number of SAR-PDU payloads for which 
the RTS period is defined. See 2.5.2.3.2 for an example. 

c) Network clocks 

For an SDH network, a 155:520 MHz network clock (fn) is available from which the following clocks 
can be derived: 

155.520 MHz* 2-*, k = 0,1 11 

As an example, to support service rates of 64 kbit/s the fnx will be 155.520 MHz * 2~ u 
(i.e. 75.9375 kHz). 

This set of derived network clocks can accommodate all service rates ranging from 64 kbit/s up to the full 
capacity of the STM-1 payload. The derived network clock to be used for a given service rate is uniquely 
specified, since the frequency ratio is constrained by 1 < fhx/fs £ 2 . 

Administrations/ROAs may use existing network clocks to support national service in a non-SDH ATM 
network. 
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d) Transport of the RTS 

The 4-bit RTS is transmitted in the serial bit stream provided by the CSI bit in successive SAR-PDU 
headers. The modulo 8 sequence count provides a frame structure over 8 bits in this serial bit stream. Four 
bits of the framed 8 bits are allocated for the RTS and the remaining 4 bits are available for other uses. If 
the four bits available for other uses are not utilized, they are set to 0. The SAR-PDU headers with the 
odd sequence count values of 1 , 3, 5 and 7 are used for RTS transport. The MSB of the RTS is placed in 
the CSI bit of the SAR-PDU header with the sequence count of 1. 

e) Plesiochronous network operation 

The issue about the accommodation of plesiochronous operation (i.e. when a common reference clock is 
not available from the network) needs to be addressed. This scenario must be accommodated in such a 
way that the recovered clock satisfies the jitter requirements specified in Recommendations G.823 and 
G.824 for Recommendation G.702 signals. However, the detailed method of dealing with plesiochronous 
operation is not standardized. 

2.5.2.2.2 Adaptive clock method 

The following is a general description of the method. The receiver writes the received information into a buffer and then 
reads it with a local clock. The fill level of the buffer is used to control the frequency of the local clock. The control is 
performed by continuously measuring the fill level around its medium position, and by using this measure to drive the 
phased-locked loop providing the local clock. The fill level of the buffer may be maintained between two limits in order 
to prevent buffer overflow and underflow. 

2.5.23 Structured data transfer (SDT) method 

2.5 .2.3.1 SDT without use of SRTS 

The CS procedure for structured data transfer uses a pointer to delineate the structure boundaries. The procedure 
supports any fixed, octet-based structure. In particular, it supports 8 kHz based structures used in circuit-mode services 
of Recommendation 1.23 1 . 

The procedure description given here is intended for data transfer which does not use the SRTS method (see 2.5.2.2.1) 
for recovery of the user clock. However, since the SDT method and the SRTS method use the CS indication in 
alternating SAR-PDU payloads, it is possible to use the two procedures simultaneously to support both structured data 
transfer and SRTS clock recovery. This combined use is described in the next subclause. 

The STRUCTURE parameter in the AAL-UNITDATA-REQUEST and AAL-UNITDATA-INDICATION primitives is 
used to convey structure information between the AAL and the AAL user. See 2.1.2 for definition of primitives 
and parameters. 

The 47 octet SAR-PDU payload used by the CS has two formats, called non-P and P format, as shown in Figure 7. 

a) Operations of the non-P format 

In the non-P format the entire CS-PDU is filled with user information. 

b) Operations of the P format 

In the P format, the first octet of the SAR-PDU payload is the pointer field. The remainder is filled with 
user information. This format may be used, only if the sequence count value in the SAR-PDU header is 0, 
2,4or6. 

The format of the pointer field is shown in Figure 8. 

The pointer field contains the binary value of the offset, measured in octets, between the end of the 
pointer field and the first start of the structured block in the 93 octet payload consisting of the remaining 
46 octets of this SAR-PDU payload and the 47 octets of the next SAR-PDU payload. This offset ranges 
between 0 and 92 inclusive. Moreover, the offset value 93 is used to indicate that the end of the 93 octet 
payload coincides with the end of a structured block whose start does not lie in the 93 octet payload. 
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FIGURE 7/1.363 

Format of SAR-PDU payload for structured data transfer method 
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FIGURE 8/1.363 
Pointer field format 



The binary value of the offset is inserted right justified in the offset field, i.e., the least significant bit of 
the offset is transmitted last The first bit of the pointer field is reserved for future standardization and 
is not used for the offset; this bit is set to 0. 

The pointer should be used as often as necessary to ensure that the structure recovery is robust. The 
frequency of pointer utilization is an item for further study. 

NOTE - The receiving CS must know the payload size of a lost SAR-PDU payload in order to maintain correct 
bit count and correct block delineation. When such a SAR-PDU has an even sequence count value, the number of 
octets to be inserted is 46 or 47 depending on the presence of the pointer field. There is a need to specify a method 
which assists the CS in determining whether the pointer field is present A possible method is to require the 
transmitting CS to use the pointer field in a systematic manner (e.g. periodically). The exact method is for 
further study. 

The first structured block to be transmitted after the AAL connection is established uses the P format with 
sequence count value in the SAR-PDU header equal to 0 and with the first octet of the structured data 
placed in the second octet of the SAR-PDU payload. 
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Partially filled cells 

The SAR-PDU payload may be filled only partially with user data in order to reduce the ceU payload 
assembly delay. In this case, the number of leading octets utilized for user information (excluding pointer 
field) in each SAR-PDU payload is a constant which is determined by the allowable ceU payload 
assembly delay. The remainder of the SAR-PDU payload consists of dummy octets. The value of the 
dummy octet is for further study. 

The offset value in the pointer field includes all octets of the SAR-PDU payload regardless of whether the 
octets are utilized for user data or consist of dummy data. 



2.5.2.3.2 SDTwithuseofSRTS 

The CS procedure for supporting structured data transfer together with SRTS clock recovery is basically a simple 
combination of the CS procedures of 2.5.2.2. 1 and 2.5.2.3. 1. 

The 47 octet SAR-PDU payload uses the two formats shown in Figure 7. 

a) Operations of the non-P format 

The non-P format is used if the sequence count value within the SAR-PDU header is 1,3 5 or 7. The 
CS indication bits carry the RTS value as described in 2.5.2.2.1. The 47 octets of the SAR-PDU payload 
are filled with user information. 

b) Operations of the P format 

The P format is used if the sequence count value within the SAR-PDU header is 0, 2, 4 or 6. The first 
octet of the SAR-PDU payload is the pointer field and the remainder is filled with user information. 

If pointer action is not needed for delineating a structured block contained in this SAR-PDU payload or in 
the next SAR-PDU payload, then the seven Bits denoting the offset are set to the dummy value of all ones. 
The CS indication is set to 1 because the pointer field is present 

If pointer action is needed for delineation, the offset and pointer operation are as described in 2.5.2.3d. 

The first structured block to be transmitted after the AAL connection is established uses the P format with 
sequence count value in the SAR-PDU header equal to 0 and with the first octet of the structured data 
placed in the second octet of the SAR-PDU payload. 

2.5.2.4 Correction method for bit errors and lost cells 

Other methods are for further study. 

2.5.2.4.1 Correction method for bit errors and cell losses for unidirectional video services 

This correction method combines forward error correction (FEC) and octet interleaving, from which a CS-PDl J s^cture 
^defined. FEC uses the Reed-Solomon (128,124) code which is able to correct up to 2 erro^ymbok gj*)or4 
erasures in the block of 128 octets. An erasure is an errored octet whose location in the block is known. The specific 
pXn^ials to be used for Reed-Solomon code are for further study. In the transmitting CS. te*<**to*f£>™ 
S is appended to 124 octets of incoming data from the upper layer. The resulting 128 octet long blocks are then 
forwarded to the octet interleaver. See Figure 9 for format of the interleave matrix. 

The octet interleaver is organized as a matrix of 128 columns and 47 rows. The interleaver is used as follows; at the 
^SSTm octet long blocks are stored row by row (one block corresponding to one row); 
are read out column by column. The matrix has 128 x 47 = 6016 octets, corresponding to 128 SAR-PDU payloads. 
These 128 SAR-PDU payloads constitute one CS-PDU. 

In this process, the loss of one SAR-PDU payload in the matrix implies one erasure to 

Erasures correspond to dummy cell payloads inserted in the cell flow when a cell loss has been detected. Misinserted 
cells which have been detected are merely discarded in the CS. 
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FIGURE 9/1.363 
Format of the interleave matrix 



For the synchronization of the CS-PDU, the CS indicator bit of the S AR-PDU header is set to 1 for the first S AR-PDU 
payload of the CS-PDU. This use of the CS indication bit precludes the use of the SDT method as specified in 2.5.2.3. 

Within any CS-PDU matrix, this method can perform the following corrections: 
- 4 cell losses ; or 

2 cell losses and 1 errored octet in each row; or 

2 errored octets in each row if there is no cell loss. 
The overhead of this method is 3. 1 %, and the delay is 128 cells. 

3 AAL type2 

3*1 Service provided by AAL type 2 

3.1.1 Definitions 

The layer services provided by AAL type 2 to the AAL user may include: 
transfer of service data units with a variable source bit rate; 
transfer of timing information between source and destination; 

indication of lost or errored information which is not recovered by AAL type 2, if needed. 

3.1.2 Primitives 

For further study. 

3.2 Interaction with the management and control planes 
3.2.1 Management plane 

The following indications may be passed from the user plane to the management plane: 
errors in the transmission of user information; 

lost or misinserted cells (further study is required on whether it is necessary to distinguish between lost 
and misinserted cells for management purposes); 
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- cells with errored AAL Protocol Control Information (AAL-PCI) (further study is required to determine if 
this indication is necessary for layer services supported by this AAL type); 

- loss of timing and synchronization; 
buffer underflow and overflow. 

3.2.2 Control plane 

For further study. 

3.3 Functions of AAL type 2 

The following functions may be performed in the AAL type 2 in order to enhance the ATM layer service: 

a) segmentation and reassembly of user information; 

b) handling of cell delay variation; 

c) handling of lost and misinserted cells; 

d) source clock frequency recovery at the receiver, 

e) recovery of the source data structure at the receiver, 

f) monitoring of AAL-PCI for.bit errors; 

g) handling of AAL-PCI bit errors; 

h) monitoring of user information field for bit errors and possible corrective action 
Other functions are for further study. 

3.4 Segmentation and Reassembly (SAR) sublayer 

3.4.1 Functions of the SAR sublayer 

For further study. 

The SAR sublayer functions are performed on an ATM-SDU basis. As the SAR accepts variable length CS-PDUs from 
the convergence sublayer, the SAR-PDUs may need to be partially filled. 

3.4.2 SAR protocol 

For further study. 

3.5 Convergence Sublayer (CS) 
35.1 Functions of the CS 

For further study. 

3.5.2 CS protocol 

For further study. . 

4 AAL type 3 

As the enhanced specification for AAL types 3 and 4 are now equivalent, the texts have been merged and referred to as 
AAL type 3/4. 

4.0 Framework of AAL type 3/4 

The convergence sublayer (CS) has been subdivided into the common part convergence sublayer (CPCS) and the service 
specific convergence sublayer (SSCS) as shown in Figure 10. Further clarification can be found in Annex B. 
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Different SSCS protocols, to support specific AAL user services, or groups of services, may be defined. The SSCS may 
also be null, in the sense that it only provides for the mapping of the equivalent primitives of the AAL to CPCS and 
vice-versa. 
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FIGURE 10/1.363 
Structure of the AAL type 3/4 



4,1 Service provided by the AAL type 3/4 

The AAL type 3/4 provides the capabilities to transfer the AAL-SDU from one user to another AAL user through the 
ATM network. 



Two modes of service are defined: message and streaming. 

a) Message mode service 

The AAL service data unit is passed across the AAL interface in exactly one AAL interface data unit 
(AAL-IDU). This service provides the transport of fixed size or variable length AAL-SDUs. 

i) In case of small fixed size AAL-SDUs an internal blocking/deblocking function in the SSCS may be 
applied; it provides the transport of one or more fixed size AAL-SDUs in one SSCS-PDU. 

ii) In case of variable length AAL-SDUs an internal AAL-SDU message segmentation/reassembling 
function in the SSCS may be applied. In this case, a single AAL-SDU is transferred in one or more 
SSCS-PDUs. 

iii) Where the above options are not used, a single AAL-SDU is transferred in one SSCS-PDU. When 
the SSCS is null, the AAL-SDU is mapped to one CPCS-SDU. 
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b) Streaming mode service 

The AAL-SDU is passed across the AAL interface in one or more AAL-IDU. The transfer of these 
AAL-IDUs across the AAL interface may occur separated in time. This service provides the transport of 
variable length AAL-SDUs. The streaming mode service includes an abort service by which the 
discarding of an AAL-SDU partially transferred across the AAL interface can be requested. 

i) An internal AAL-SDU message segmentation/reassembUng function in the SSCS may be applied. In 
this case, all the AAL-IDUs belonging to a single AAL-SDU are transferred in one or more SSCS- 
PDU. 

ii) An internal pipelining function may be applied. It provides the means by which the sending AAL 
entity initiates the transfer to the receiving AAL entity before it has the complete AAL-SDU 
available. 

iii) Where option i) is not used, all the AAL-IDUs belonging to a single AAL-SDU are transferred in 
one SSCS-PDU. When the SSCS is null, the AAL-IDUs belonging to a single AAL-SDU are 
mapped to one CPCS-SDU 

A summary of the options applicable to the modes of services described above is found in Tables 3 and 4. 



TABLE 3/1.363 
Combination of service mode and internal function 





AAL-SDU message 
segmentation/reassembly 
in the SSCS 


AAL-SDU 
blocking/deblocking 
in the SSCS 


Pipelining 


Message 

Option 1 
Option 2 


0 
N/A 


N/A 
0 


N/A 
N/A 


Streaming 


0 


N/A 


0 


Option 1 Long variable size i 
Option 2 Short fixed size SD 
0 Optional 
N/A Not applicable 


>DUs 
Us 



TABLE 4/1.363 



Combination of service mode at the sending and receiving side 





Sender 




Receiver 


MM/Block 


MM/Seg 


SM 


MM/Deblocking 


A 


N/A 


N/A 


MM/Reasssembly . 


N/A 


A 


A 


SM 


N/A 


A 


A 



MM Message mode 
SM Streaming mode 
A Applicable 
N/A Not applicable 

NOTE - An end-to-end specification of the SDU length in message mode with blocking/deblocking i; 
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Both modes of service may offer the following peer-to- peer operational procedures: 
Assured operations 

Every assured AAL-SDU is delivered with exactly the data content that the user sent. The assured service 
is provided by retransmission of missing or corrupted SSCS-PDUs. Flow control is provided as a 
mandatory feature. The assured operation may be restricted to point-to-point ATM adaptation layer 
connections. 

- Non-assured operations 

Integral AAL-SDUs may be lost or corrupted. Lost and corrupted AAL-SDUs will not be corrected by 
retransmission. An optional feature may be provided to allow corrupted AAL-SDUs to be delivered to the 
user (i.e. optional error delivery). Flow control may be provided as an option. 



4.1.1 Description of AAL connections 



The AAL type 3/4 provides the capabilities to transfer the AAL-SDU from one AAL-SAP to one or more AAL-SAPs 
through the ATM network (see Figures 1 1 and 12). The AAL-users will have the capability to select a given AAL-SAP 
associated with the QOS required, to transport that AAL-SDU (for example, delay and loss sensitive QOS). 

AAL type 3/4 makes use of the service provided by the underlying ATM layer (see Figure 13). Multiple AAL 
connections may be associated with a single ATM layer connection, allowing SAR-PDU multiplexing at the AAL. The 
AAL user selects the QOS provided by the AAL through the choice of the AAL-SAP used for data transfer. 
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FIGURE 11/1363 
Point-to-point AAL connection 



4.1.2 Primitives 

The functional model for AAL type 3/4 as contained in Annex C shows the interrelation between the SAR, CPCS 
and SSCS sublayers, and the SAR and CPCS primitives. 

4.1.2.1 Primitives for the AAL 

These primitives are service specific and are for further study. 
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FIGURE 12/1363 
Point-to-raultipoint AAL connection 
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FIGURE 13/1.363 
Relation between AAL-SAP and ATM-SAP 



The SSCS may be null, in the sense that it only provides for the mapping of £££ 
CPCS andTce-versa. In this case, the primitives for the AAL are equivalent to those for the CPCS (4.L2 2) but 

r s ^ ^ L - u - Ab ^ 

tion and AAL-P-Abort-indication f consistent with the primitive nammg convention at a SAP. 
4.1.2-2 Primitives for the CPCS of the AAL 
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4.1.2.2.1 Primitives for the data transfer service 

- CPCS-UNITDATA-invoke and the CPCS-UNITDATA-signal 

These primitives are used for the data transfer. The following parameters are defined: 

interface data (ID): This parameter specifies the interface data unit exchanged between the CPCS 
and the SSCS entity. The interface data is an integral multiple of one octet. If the CPCS entity is 
operating in the message mode service, the interface data represents a complete CPCS-SDU; when 
operating in the streaming mode service, the interface data does not necessarily represent a complete 
CPCS-SDU. 

More (M): In the message mode service, this parameter is not used. In the streaming mode 
service, this parameter specifies whether the Interface Data communicated contains a 
beginning/continuation of a CPCS-SDU or the end of / complete CPCS-SDU! 

- Maximum Length (ML): In the message mode service, this parameter is not used. In the streaming 
mode service, this parameter indicates the maximum length of the CPCS-SDU. This parameter is 
required with the first invoke or signal primitive related to a certain CPCS-SDU; in all other cases, 
this parameter is not used. 

- Reception Status (RS): This parameter indicates that the interface data delivered may be corrupted. 
This parameter is only utilized if the corrupted data delivery option is used. 

Depending on the service mode (message or streaming mode service, discarding or delivery of errored information), not 
all parameters are required. This is summarized in Table 5. 



TABLE 5/1.363 
Parameters of the CPCS-UNITDATA 



Parameter 


Type 


MM 


SM 


Comments 


Interface data (ID) 


Invoke signal 


M 


M 


Whole or partial CPCS-SDU 




M 


M 




More(M) 


Invoke signal 




M 


M = 0 End of CPCS-SDU 






M 


M = 1 Not end of CPCS-SDU 


Maximum length (ML) 


Invoke signal 




M* 


Maximum length of CPCS-SDU 




O* 


Reception status (RS) 


Invoke signal 






Indication of corrupted data 






O 


0 




MM Message mode service 










SM Streaming mode service 










M Mandatory 










0 Optional 










Not present 










M* Mandatory with the first invoke or signal primitive related to a certain CPCS-SDU, otherwise absent. 


0* Optional with the first invoke or signal primitive related to a certain CPCS-SDU, otherwise absent 



4.1.2.2.2 Primitives for the abort service 

These primitives are used in the streaming mode service. 

a) CPCS-U-Abort-invoke and CPCS- U- Abort-signal 

This primitive is used by the CPCS user to invoke the abort service. It is also used to signal to the CPCS 
user that a partially delivered CPCS-SDU is to be discarded by instruction from its peer entity. No 
parameters are defined. 

This primitive is not used in message mode. 
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b) CPCS-P-Abort-signal 

This primitive is used by the CPCS entity to signal to its user that a partially delivered CPCS-SDU is 
to be discarded due to the occurrence of some error in the CPCS or below. No parameters are defined. 

This primitive is not used in message mode. 
4.1.23 Primitives for the SAR sublayer of the AAL 

These primitives model the exchange of information between the SAR sublayer and the CPCS. 

As there exists no service access point (SAP) between the sublayers of the AAL type 3/4, the primitives are called 
"invoke" and "signal" instead of the conventional "request" and "indication" to highlight the absence of the SAP. 

4.1.23.1 Primitives for the data transfer service 

- SAR- UNITDA TA -invoke and the SAR- UNITDATA-signal 

These primitives are used for the data transfer. The following parameters are defined: 

1) Interface Data (ID): This parameter specifies the interface data unit exchanged between the SAR and the 
CPCS entity. The interface data is an integral multiple of one octet. The interface data does not 
necessarily represent a complete SAR-SDU. 

2) More (M): This parameter specifies whether the interface data communicated contains the end of 
the SAR-SDU. 

If the More parameter is set to M=l, the interface data parameter must contain an integral multiple of 
44 octets. 

3) Reception Status (RS): This parameter indicates that the interface data delivered may be corrupted. This 
parameter is only utilized if the corrupted data delivery option is used. 

4.1.23.2 Primitives for the abort service 

a) SAR-U -Abort-invoke and SAR-U -Abort-signal 

This primitive is used by the SAR user to invoke the abort service. It is also used by the SAR entity to 
signal to the SAR user that a partially delivered SAR-SDU is to be discarded by instruction from its peer 
entity. This primitive has no parameters. 

b) SAR-P-Abort-signal 

This primitive is used by the SAR entity to signal to its user that a partially delivered SAR-SDU is to be 
discarded due to the detection of some error. This primitive is only used if the corrupted data delivery 
option is not used. This primitive has no parameters. 

4.2 Interaction with the management and control plane 

4.2.1 Management plane 

For further study. 

4.2.2 Control plane 

For further study. 

4.3 Functions, structure and coding of AAL type 3/4 
43.1 Segmentation and Reassembly (SAR) sublayer 
43.1.1 Functions of the SAR sublayer 

The SAR sublayer functions are performed on an SAR-PDU basis. The SAR sublayer accepts variable length 
SAR-SDUs from the convergence sublayer (CS) and generates SAR-PDUs containing up to 44 octets of SAR-SDU data. 

The SAR sublayer functions provide the means for the transfer of multiple variable length SAR-SDUs concurrently over 
a single ATM layer connection between AAL entities. 
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a) Preservation of SAR-SDU 

This function preserves the SAR-SDU by providing for a segment type indication and a SAR-PDU 
pay load Length indication. The SAR-PDU payload length indication identifies the number of octets of 
SAR-SDU information contained within the SAR-PDU payload. The segment type indication identifies a 
SAR-PDU as a beginning of message (BOM), continuation of message (COM), end of message (EOM), 
or single segment message (SSM). 

b) Error Detection and Handling 

This function provides the means to detect and handle: 

- bit errors in the SAR-PDU; 

- lost or gained SAR-PDUs. 

SAR-PDUs with bit errors are discarded. An optional feature may be provided to allow corrupted 
SAR-PDUs to be delivered to the CPCS (i.e. optional error delivery). However, if the optional 
multiplexing and demultiplexing of SAR connections is performed, such an optional errored delivery 
service may deliver an errored SAR-SDU to the wrong state machine. SAR-SDUs with lost or gained 
SAR-PDUs are discarded or are optionally delivered to the CPCS. When delivering errored information, 
an appropriate indication is associated with the information. 

c) SAR-SDU sequence integrity 

This function assures that the sequence of SAR-SDUs is maintained within one SAR connection. 

d) Multiplexing/demultiplexing 

This function provides for the optional multiplexing and demultiplexing of multiple SAR connections. 9 
The number of SAR connections supported over an ATM connection shall be negotiated at connection 
establishment The default number of CPCS connections shall be one. Within a given SAR connection, 
sequence integrity will be preserved. 



43.1*2 SAR-PDU structure and coding 

The SAR sublayer functions require a 2 octet SAR-PDU header and a 2 octet SAR-PDU trailer. The SAR-PDU header 
and trailer together with the 44 octets of SAR-PDU payload comprise the 48 octet ATM-SDU (cell payload). The sizes 
and positions of fields for the SAR-PDU structure are given in Figure 14. 

The coding of the SAR-PDU conforms to the coding conventions specified in 2.1/1.361. There are two types of 
SAR-PDU: Data-SAR-PDUs and Abort-SAR-PDUs. 

43.1.2.1 Data-SAR-PDU coding 

a) Segment type (ST) field 

The segment type indication identifies a SAR-PDU as containing a beginning of message (BOM), a 
continuation of message (COM), an end of message (EOM), or a single segment message (SSM). The 
association between the encoding and the meaning of the segment type field is shown in Table 6. 

b) Sequence number ( SN) field 

Four bits are allocated to the sequence Number field allowing the stream of SAR-PDUs of a CPCS-PDU 
to be numbered modulo 16. 

Each SAR-PDU belonging to a SAR-SDU (and hence associated with a given MID value) will have its 
sequence number incremented by one relative to its previous sequence number. The receiver checks the 
sequence of the sequence number field of SAR-PDUs derived from one SAR-SDU and does not check 
the sequence of the sequence number field of the SAR-PDUs derived from successive SAR-SDUs. As the 
receiver does not check the sequence number continuity between SAR-SDUs, the sender may set the 
sequence number field to any value from 0 to 15 at the beginning of each SAR-SDU. 
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e) Abort 



This function provides for the means to abort a partially transmitted SAR-SDU. 
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MID Multiplexing identification (1 0 bits) 

LI Length indication (6 bits) 

CRC Cyclic redundancy check code (10 bits) 



SAR-PDU 



T1B11370-90/d14 



FIGURE 14/1.363 
SAR-PDU format for AAL type 3/4 



TABLE 6/1.363 
Coding of segment type field 



Segment type 


Encoding 


Usage 


BOM 


10 


Beginning of message 


COM 


00 


Continuation of message 


EOM 


01 


End of message 


SSM 


11 


Single segment message 



c) Multiplexing identification (MID) field 

This field is used for multiplexing. If no multiplexing is used, this field shall be set to zero. 

In connection oriented applications it may be used to multiplex multiple SAR connections on a 
single ATM layer connection. The following restrictions may apply: 

- Multiplexing/demultiplexing on a single ATM layer connection using the MID field will be on a 
user-to-user basis. 

- A single ATM layer connection containing multiplexed AAL type 3/4 traffic will be administered as 
a single entity. 

In connectionless and connection oriented applications, all S AR-PDUs of a SAR-SDU will have , the same 
MID field value. The MID field is used to identify SAR-PDUs belonging to a particular SAR-SDU. The 
MID field assists in the interleaving of SAR- PDUs from different SAR-SDUs and reassembly of these 
SAR-SDUs. 

An implementation of AAL type 3/4 is not obliged to support the full range of MID field values. The 
mechanism for restricting the range of MID field values is for further study. Examples of possible 
mechanisms would include those based on dynamic negotiation or on signalling. 
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d) SAR-PDU payload field 

The S AR-SDU information is left justified within the SAR-PDU payload field. The remaining octets of 
the SAR-PDU payload field may be set to "0" and are ignored at the receiving end. 

e) Length indication ( U) field 

The length indication field is binary encoded with the number of octets of SAR-SDU information that are 
included in the SAR-PDU payload field. Permissible values of this field, depending on the coding of the 
segment type field are shown in Table 7. See also Figure B.3. Combined SAR and CPCS PDU format. 

TABLE 7/1.363 



Permissible values of the length Indication field 



Segment type 


Permissible value 


BOM 




44 


COM 




44 


EOM 




4 ... 44, 63 (Note) 


SSM 




8. ..44 


NOTE - The value "63" is used in the Abort-S AR-PDU (see 4.3. 1 .2.2) 



9 



f) CRC field 

The CRC field shall be a 10-bit sequence. It shall be the remainder of the division (modulo 2) by the 
generator polynomial of the product of, x 10 and the content of the SAR-PDU, including the SAR-PDU 
header, SAR-PDU payload, and length indication field of the SAR-PDU trailer. Each bit of the 
concatenated fields mentioned above are considered as coefficients (modulo 2) of a polynomial of degree 
373. The CRC- 10 generator polynomial is: 

G(jc)= 1 +x + jc4 + x3 + *9 + Jtl0 

The result of the CRC calculation is placed with the least significant bit right justified in the CRC field. 
The CRC-10 is used to detect bit errors in the SAR-PDU. 

43.1.2.2 Abort-S AR-PDU coding 

The coding of the Abort-SAR-PDU conforms to the structure and coding specified above with the exception that 

1) the segment type field shall be coded as EOM; 

2) the payload field may be set to zero and is ignored at the receiving end; 

3) the length indication field shall be set to 63. 

432 Convergence Sublayer (CS) 

43.2.1 Functions, structure and coding for the CPCS 

The CPCS has the following service characteristics. 

- Non-assured transfer of user data frames with any length measured in octets from 1 to 65,535 octets and 
with the possibility of further extension (how much it can be extended is for further study). 

- One or more "CPCS connections" may be established between two CPCS peer entities (no switching of 
CPCS connections will be supported). The maximum number of CPCS connections that can be 
established is defined by the end system with the lowest capacity. 



26 Recommendation 1363 (03/93) 



COPYRIGHT international Telecommunications Onion/ITU Telecommunications 
Licensed hv Information Handling Services 



- The CPCS connections will be established by management or by the control plane. 

- Error detection and indication (cell loss or gain). 

- CPCS-SDU sequence integrity on each CPCS connection. 

The CPCS has the basic functionality to support a connectionless network access protocol (CLNAP) layer (Class D) as 
well as a frame relaying telecommunication service in Class C. For the CLNAP layer (Class D) there is no need for any 
service specific convergence sublayer. 

4 .3.2.1.1 Functions of the CPCS 

The CPCS functions are performed per CPCS-PDU. The CPCS provides several functions in support of the CPCS 
service user. Some of the functions provided depend on whether the CPCS service user is operating in message or 
streaming mode. 

i) Message mode service 

The CPCS-SDU is passed across the CPCS interface in exactly one CPCS-IDU. This service provides the 
transport of a single CPCS-SDU in one CPCS-PDU. 

ii) Streaming mode service 

The CPCS-SDU is passed across the CPCS interface in one or more CPCS-IDUs. The transfer of these 
CPCS-IDUs across the CPCS interface may occur separated in time. This service provides the transport of 
all the CPCS-IDUs belonging to a single CPCS-SDU into one CPCS-PDU. The streaming mode service 
includes an abort service by which the discarding of a CPCS-SDU partially transferred across the 
interface can be requested. 

The functions implemented by the CPCS include: 

a) Preservation of CPCS-SDU 

This function provides for the delineation and transparency of CPCS-SDUs. 

b) Error detection and handling 

This function provides for the detection and handling of CPCS-PDU corruption. Corrupted CPCS-SDUs 
are either discarded or are optionally delivered to the SSCS. The procedures for delivery of corrupted 
CPCS-SDUs are for further study. When delivering errored information to the CPCS user, an error 
indication is associated with the delivery. 

Examples of detected errors would include: Btag/Etag mismatch, received length and CPCS-PDU length 
field mismatch, buffer overflow, improperly formatted CPCS-PDU, and errors indicated by the SAR 
sublayer. 

c) Buffer allocation size 

This function provides for the indication to the receiving peer entity of the maximum buffering 
requirements to receive the CPCS-PDU. 

d) Abort 

This function provides for the means to abort a partially transmitted CPCS-SDU. 
Other functions are for further study. 

43J.1.2 CPCS structure and coding 

The CPCS functions require a 4 octet CPCS-PDU header and a 4 octet CPCS-PDU trailer. In addition, a padding field 
provides for a 32 bit alignment of the CPCS-PDU payload. The CPCS-PDU header and trailer together with the padding 
field and the CPCS-PDU payload comprise the CPCS-PDU. The sizes and positions of fields for the CPCS-PDU 
structure are given in Figure 15. 

The coding of the CPCS-PDU conforms to the coding conventions specified in 2.1/1.361. 
a) Common part indicator ( CP!) field 

The CPI field is used to interpret subsequent fields for the CPCS functions in the CPCS-PDU header and 
trailer. The counting units for the values specified in the BAsize and length fields may be indicated; other 
uses are for further study. These uses shall be restricted to the CPCS and SAR sublayer functions 
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including the means to identify related AAL layer management messages. These messages in the future 
could be used to perform layer management functions which may include: performance and fault 
monitoring, MID allocation, and transfer of OAM messages. 



CPCS-PDU header 



CPCS-PDU payioad 



CPI 


j Btag 


BASize 


< 


CPCS-PDU header 


— ► 



CPCS-PDU trailer 



AL 


Etag 


Length 


CPCS-PDU trailer 
w ■• ► 



CPCS-PDU 



CPI Common part indicator (1 octet) 

Btag Beginning tag (1 octet) 

BASize Buffer allocation size (2 octets) 

PAD Parting (0 ... 3 octets) 

AL Alignment (1 octet) 

Etag End tag (1 octet) 

Length Length of CPCS-PDU payioad {2 octets) 



T181 7690-92*115 



FIGURE 15/1363 
CPCS-PDU format for AAL type 3/4 



Table 8 shows the agreed coding of the CPI field and indicates the related semantics of the B Asize and 
length fields. Additional encodings and uses of the CPI field are for further study. 



TABLE 8/1.363 
CPI field encoding 



CPI encoding 


B Asize field semantics 


Length field semantics 


00000000 


Buffer allocation requirements in octets 


Equals length of CPCS-PDU payioad 
in octets 


Other values are reserved and 
are for future standardization 


For further study 


For further study 



b) Beginning tag (Btag) field 

This field allows the association of the CPCS-PDU header and trailer. The sender inserts the same value 
in the Btag and the Etag in the trailer for a given CPCS-PDU and changes the value for each successive 
CPCS-PDU. The receiver checks the value of the Btag in the CPCS header with the value of the Etag in 
the CPCS trailer. It does not check the sequence of the Btag/Etags in successive CPCS-PDUs. 
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As an example, a suitable mechanism is as follows: The sender increments the value placed in the Btag 
and Etag fields for each successive CPCS-PDU sent over a given MID value. Btag values are cycled up to 
modulo 256. 

c) Buffer allocation size indication (BAsize) field 

The BAsize field indicates to the receiving peer entity the maximum buffering requirements to receive the 
CPCS-SDU In message mode the BAsize value is encoded equal to the CPCS-PDU payload length. In 
streaming mode, the BAsize value is encoded equal to or greater than the CPCS-PDU payload length. 

The buffer allocation size is binary encoded as number of counting units. The size of the counting units is 
identified by the CPI field. 

NOTE - The length of the CPCS-PDU payload is limited to the maximum value of the BAsize field multiplied 
by the value of the counting unit. 

d) Padding (PAD) field 

Between the end of the CPCS-PDU payload and the 32 bit aligned CPCS-PDU trailer, there will be from 
0 to 3 unused octets. These unused octets are called the padding (PAD) field; they are strictly used as 
filter octets and do not convey any information. It may be set to "0" and its value is ignored at the 
receiving end. This padding field complements the CPCS-PDU payload to an integral multiple of 4 octets. 

The function of the PAD field is shown in Figure 16. 
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jURADgl PAD field Format of the CPCS-PDU 



Hdr CPCS header 

Info CPCS payload 

Trl CPCS trailer 



FIGURE 16/1.363 
Function of the PAD field 
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e) Alignment (AL) field 

The function of the alignment field is to achieve 32-bit alignment in the CPCS-PDU trailer. The 
alignment field complements the CPCS-PDU trailer to 32 bits. This unused octet is strictly used as a filler 
octet and does not convey any information. 

The alignment field shall be set to zero. 

f) End tag (Etag) field 

For a given CPCS-PDU, the sender shall insert the same value in this field as was inserted in the Btag 
field in the CPCS-PDU header to allow the association of the CPCS-PDU trailer with its CPCS-PDU 
header. 

g) Length field 

The length field is used to encode the length of the CPCS-PDU payload field. This field is also used by 
the receiver to detect the loss or gain of information. 

The length is binary encoded as number of counting units. The size of the counting units is identified by 
the CPI field. 

NOTE - The length of the CPCS-PDU payload is limited to the maximum value of the length field multiplied 
by the value of the counting unit. 



43.2*2 Functions, structure and coding for the SSCS 

The CPCS has the basic functionality to support a connectionless network layer (Class D) as well as a frame relaying 
telecommunication service in Class C. For the connectionless network layer (Class D) there is no need for any service 
specific convergence sublayer. Otherwise the functions, structure and coding for the SSCS are for further study. 

4.4 Procedures 

There exists one segmentation and reassembly state machine per multiplexing identification (MID) field value. For each 
such state machine, the value of this field must be known by the protocol state machines. 

4.4.1 Procedures of the SAR sublayer 

The structure and coding of the SAR-PDU is defined in 4.3.1.2. 

4.4.1.1 State variables of the SAR sublayer at the sender side 

The SAR sender maintains the following state variable: 
- sndJSN 

This variable is used to set the sequence number field of the SAR-PDU header. It is incremented 
modulo 16 after each SAR-PDU of a SAR-SDU has been forwarded to the ATM layer for transmission. 

4.4.1 Procedures of the SAR sublayer at the sender side 

Hie state machine of the SAR sender is shown in Figure 17. 
Table 9 defines the states for the SAR sender. 



TABLE 9/1.363 
State definitions for the SAR sender 



State 


Definition 


IDLE 
STREAM 


Waiting to begin to transmit a new S AR-SDU 
Transmitting a SAR-SDU in streaming mode 
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SAR-U-Abort-invoke 



FIGURE 17/1363 
State transition diagram for the SAR sender 



1) When the SAR connection is established, the SAR sender shall proceed to the IDLE state. Whenever 
entering the IDLE state, the SAR sender may change its state variable snd_SN to any value from 0 to 15. 

2) For each SAR-PDU, the SAR sender shall set the MID field to the values governing this state machine. 
The sequence number field is set to the value of the state variable snd.SN and the state variable snd_SN 
is incremented by one (modulo 16). 

3) Upon receiving a SAR-UNITDATA-invoke primitive from the CPCS, the SAR sender shall start the 
segmenting process. If the Interface Data has a length of more than 44 octets, the SAR sender wil 
generate more than one SAR-PDU. In all SAR-PDUs (except possibly the last one), the SAR-PDU 
payload field shall be filled with 44 octets of CPCS-PDU information. 

4) In each SAR-PDU, the length indication field shall be set to the number of octets of SAR-SDU data 
carried in the payload and the CRC field shall be computed as specified in 4.3.1.2. 

5) If the SAR sender is in the IDLE state, it shall set the most significant bit of the segment type field in the 
first SAR-PDU to "1" ("BOM" or "SSM"); in all subsequent SAR-PDUs, this bit shall be set to "0 
("COM" or "EOM"). If the SAR sender is in the STREAM state, the most significant bit of the ST field 
of all SAR-PDUs shall be set to "0". 

6) If the M parameter in the SAR-UNITDATA-invoke primitive has the value "0", the SAR sender shall set 
the least significant bit of the segment type field in the last SAR-PDU to "1" ("EOM" or "SSM ); in all 
other cases, this bit shall be set to "0" ("BOM" or "COM"). 

7) Upon completion of the segmenting process, the SAR sender shall proceed either to the IDLE -state or the 
STREAM state. If the M parameter in the SAR-UNITDATA-invoke primitive has the value 0 , the SAR 
sender shall proceed to the IDLE state; otherwise, it shall proceed to the STREAM state. 

8) The SAR sender shall ignore a SAR-U-Abort-invoke primitive when it is in the IDLE state When in the 
STREAM state, the SAR sender shall generate and transmit an Abort-SAR-PDU and proceed to the IDLE 
state. 

NOTE - This description of the SAR sender procedures is valid for all service modes of the CPCS. If the CPCS 
passes only complete CPCS-PDUs to the SAR sublayer, the state machine remains always in the IDLE state. 

4.4.1 3 State variables of the SAR sublayer at the receiver side 

The SAR receiver maintains the following state variable: 
- rcvJSN 

This variable is used to detect loss or gain of SAR-PDUs. After the receipt of an SAR-PDU with a 
segment type field that indicates "COM' or "EOM", the SAR receiver compares the value in the sequence 
number field with this state variable. If they are equal, the SAR-PDU is assumed to be in sequence and 
the rcv_SN is incremented by one modulo 16. 
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If the segment type field of a SAR-PDU indicates "BOM" or "SSM", the sequence number field is not 
compared with rcv_SN; however, the state variable rcv_SN is set to one greater (modulo 16) than the 
value in the sequence number field 

4.4.1.4 Procedures of the SAR sublayer at the receiver side 

The state machine of the SAR receiver is shown in Figure 18. 
Table 10 defines the states for the SAR receiver. 



SSM SAR-PDU 

detection of error in any SAR-PDU 
COM SAR-PDU 
EOM SAR-PDU 
Abort-SAR-PDU 



BOM SAR-PDU 




BOM SAR-PDU 
COM SAR-PDU 



EOM SAR-PDU 
'detection of error in any SAR-PDl 
Reassembly timer expiry 
SSM SAR-PDU 
Abort-SAR-PDU 




T181772)-92/d18 



FIGURE 18/L363 
State transition diagram for the SAR receiver 



TABLE 10/1.363 
State definitions for the SAR receiver 



State 


Definition 


IDLE 
REASS 


Waiting to begin to receive a new SAR-SDU 
Receiving a SAR-SDU 



The following procedures are specified for an SAR receiver that does not deliver errored data to the receiving CPCS. 
The procedures describing the delivery of errored information are for further study. 

NOTE - The term "delivery to the CPCS" refers to the communication across the SAR - CPCS sublayer boundary via a 
SAR-UNITDATA-signal primitive. 

1) All illegal SAR-PDUs are ignored An illegal SAR-PDU is a SAR-PDU with either 

- a CRC verification error, or 

- an unexpected MID field value. 

NOTE - The discarding of illegal SAR-PDUs actually takes place prior to assigning the SAR-PDU to a reassembly 
process governed by a particular MID field value. 
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2) For every SAR-PDU received, the SAR receiver verifies that the value of the length indication field is 
permissible given the coding of the segment type field (at Table 7 "Permissible i values of *e UngJ 
Indication Field"). If the value is outside the allowed range, the SAR-PDU is discarded. Ifthe SAR 
receiver is in the REASS state, it shall issue a SAR-P-Abort-signal primitive to the receiving CPCS. In all 
cases, it shall proceed to the IDLE state. 

3) In the absence of errors and irrespective of the state in which the SAR receiver is, the number of octets 
indicated in the length indication field are sent from the SAR-PDU payload to the CPCS. If the segment 
type field indicates "EOM" or "SSM'\ the M parameter is set to "0" and the SAR receiver proceeds to the 
IDLE state; otherwise, if the segment type field indicates "BOM" or "COM", the M parameter is set to 
"1" and the SAR receiver proceeds to or remains in the REASS state. 

The following error recovery procedures apply: 

4) If the SAR receiver is in the IDLE state and receives a SAR-PDU whose segment type field indicates 
"COM" or "EOM", the SAR receiver shall ignore the SAR-PDU. 

5) If the SAR receiver is in the REASS state and receives a SAR-PDU whose segment type field indicates 
"BOM" or "SSM", the SAR receiver shall issue a SAR-P-Abort-signal to the receiving CPCS; the 
SAR-PDU shall be processed normally as described in 3) above. 

6) If the SAR receiver is in the REASS state and it receives a SAR-PDU whose value in the sequence 
number field is not the same as the value of the state variable rcv.SN, it shall issue a S AR4>-A^-sigDd 
to the receiving CPCS, in addition, if the segment type field indicates "COM" or <<EOM'\ ^f AR-PDU 
is discarded and the SAR receiver shall proceed to the IDLE state; otherwise, the SAR-PDU shall be 
processed normally as described in 3) above. 

7) If the SAR receiver receives an Abort-SAR-PDU and is in the IDLE state, this SAR-PDU shall be 
ignored; if in the REASS state, the SAR receiver shall issue a SAR-U- Abort-signal primitive and proceed 
to the IDLE state. 

If a reassembly timer is supported, the following procedures apply: 

8) When after the processing of a SAR-PDU the SAR receiver reaches the REASS state, the reassembly 
timer shall be (re-)started. 

9) If the timer is still running when the SAR receiver transitions from the REASS state to the IDLE state, the 
timer shall be stopped. 

10) If the timer expires (the SAR receiver is in the REASS state) the SAR receiver shall issue a 
SAR-P-Abort-signal to the receiving CPCS and shall proceed to the IDLE state. 

Other reassembly timer procedures are for further study. 

NOTE - The timer value may be dependent on the AAL connection but is not specified in this Recommendation. 

4.4.2 Procedures of the CPCS for the message mode service 
The structure and coding of the CPCS-PDU are defined in 4.3.2. 1 . 

4.4.2.1 State variables of the CPCS at the sender side 

The CPCS sender maintains the following state variable: 
sndJBEtag 

This variable is used to set the Btag field in the CPCS-PDU header and the Etag field in the CPCS-PDU 
trailer. 

4.4.2.2 Procedures of the CPCS at the sender side for the message mode service 

The state machine of the CPCS sender is shown in Figure 19. 
Table 1 1 defines the states for the CPCS sender. 
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FIGURE 19/1363 
State transition diagram for the CPCS sender 



TABLE 11/1.363 
State definitions for the CPCS sender 



State 


Definition 


IDLE 


Waiting to transmit a new CPCS-SDU 



1) When the CPCS connection is established, the CPCS sender shall set its state variable snd_BEtag to any 
value from 0 to 255. 

2) Upon receiving an CPCS-UNITDATA-invoke from the CPCS user, the CPCS sender shall construct the 
CPCS-PDU header, place the received CPCS-SDU into the CPCS-PDU payload, construct the PAD field 
and construct the CPCS-PDU trailer. The CPCS-PDU is then forwarded in its entirety (i.e. the- 
M parameter is set to "0") to the SAR sublayer via the SAR-UNTTDATA-invoke primitive for 
segmentation and transmission. 

3) After forwarding the CPCS-PDU to the SAR sublayer, the CPCS sender shall modify its state variable 
snd_BEtag. This modification must assure that the CPCS receiver can unambiguously associate the 
CPCS-PDU header and trailer of every CPCS-PDU even in the presence of loss of information (cell 
losses across CPCS-PDU boundaries). At the minimum, the snd_BEtag shall be set to any value different 
from the current one (modulo 256). 

NOTE - A suitable mechanism is to increment the state variable sndJJEtag by one (modulo 256) after each 
CPCS-PDU. 

4A23 State variables of the CPCS at the receiver side 

The CPCS receiver maintains the following state variables: 

1) rcvJBEtag 

This variable is used to assure that a received CPCS-PDU trailer belongs to the CPCS-PDU currendy 
being reassembled. This is achieved by copying the Btag field value to this state variable when processing 
the" CPCS-PDU header, when processing the associated CPCS-PDU trailer, the value in the Etag field is 
compared to the value in the state variable. 

2) rcvJAsize 

This variable is used to assure that attempts to assemble CPCS-PDUs that are longer than the requested 
BAsize will fail. 

4.4.2.4 Procedures of the CPCS at the receiver side 

The state machine of the CPCS receiver is shown in Figure 20. 
Table 12 defines the states for the CPCS receiver. 
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SDU > BAsize 
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SAR-UNITDATA Signal <M = 1) 



FIGURE 20/1.363 
State transition diagram for the CPCS receiver 



TABLE 12/1.363 
State definitions for the CPCS receiver 



State 


Definition 


IDLE 

REASS 

ABORT 


Waiting to begin to reassemble a new CPCS-PDU 
Reassembling a CPCS-PDU 
Aborting an illegal CPCS-PDU 



The following procedures are specified for a CPCS receiver that does not deliver errored data to the receiving CPCS 
user. Procedures for the optional delivery of errored information are for further study. 

1) When the CPCS receiver is in the IDLE state and it receives a SAR-UNIXDATA-signal primitive from 
the SAR sublayer, the first four octets of the information represent the CPCS-PDU header. 
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If the CPI field in the CPCS-PDU header is illegal, the CPCS receiver shall proceed to the ABORT state 
if the M parameter is set to "1" or to the IDLE state if the M parameter is set to "0". Otherwise, the CPCS 
receiver shall copy the value of the Btag field into the rcv_BEtag state variable. It also shall set the state 
variable rcv_BAsize to the value of the BAsize field. The allocation of a reassembly buffer with at least 
the size indicated in the state variable rcv_BAsize is implementation dependent 



NOTES 



1 This procedure description may copy up to three octets of the PAD field into the reassembly buffer before 
processing the CPCS-PDU trailer. 



2 When the CPCS receiver is in the REASS state and it receives a SAR-UNTTDATA-signal primitive from the 
SAR sublayer, no CPCS-PDU header information is present. 



2) When the CPCS receiver is in the IDLE state or the REASS state and it receives a SAR-UNTTDATA- 
signal primitive from the SAR sublayer with the M parameter set to "0'\ the last 4 octets of the 
information represents the CPCS-PDU trailer. If the alignment field in the CPCS-PDU trailer is not equal 
to zero, the CPCS receiver shall free the reassembly buffer and proceed to or remain in the IDLE state. 



The CPCS receiver shall .verify that the value of the Etag field is equal to the value in the rcv_BEtag state 
variable. If they are not equal, the CPCS receiver shall free the reassembly buffer and proceed to or 
remain in the IDLE state. 



If the value of the length field in the CPCS-PDU trailer is greater than the already reassembled • 
information in the reassembly buffer plus the mformation in the interface data of the primitive currently 
processed (without the CPCS-PDU trailer and the CPCS-PDU header), the CPCS receiver shall free the 
reassembly buffer and proceed to or remain in the IDLE state. 



If the value of the length field in the CPCS-PDU trailer is less than the already reassembled information 
in the reassembly buffer plus the information in the interface data of the primitive currently processed 
(without the CPCS-PDU trailer and the CPCS-PDU header) minus 3, the CPCS receiver shall free the 
reassembly buffer and proceed to or remain in the IDLE state. 



If the already reassembled information in the reassembly buffer plus the information in the interface data 
of the primitive currently processed (without the CPCS-PDU trailer and the CPCS-PDU header) is greater 
than the state variable rcv_BAsize plus the maximum pad field length, the CPCS receiver shall free the 
reassembly buffer and proceed to or remain in the IDLE state. 

The CPCS receiver shall copy the information in the interface data of the primitive currently processed 
(without the CPCS-PDU trailer and possibly the CPCS-PDU header) to the reassembly buffer. The CPCS 
receiver shall then send the reassembled CPCS-SDU to the CPCS user in the interface data of a 
CPCS-UNITDATA-signal primitive; the amount of information in the interface data is equal to the value 
of the length field of the CPCS-PDU trailer. It shall also free the reassembly buffer, and proceed to or 
remain in the IDLE state. 



3) When the CPCS receiver is in the IDLE state or the REASS state and it receives a SAR-UNTTDATA- 
signal primitive from the SAR sublayer with the M parameter set to "1", no CPCS-PDU trailer is present 

If the already reassembled information in the reassembly buffer plus the information in the interface data 
of the primitive currently processed (without possibly the CPCS-PDU header) is greater than the state 
variable rcv_BAsize plus the maximum pad field length, the CPCS receiver shall free the reassembly 
buffer and proceed to the ABORT state. Otherwise, the CPCS receiver shall copy the information in the 
interface data of the primitive currently processed (without possibly the CPCS-PDU header) to the 
reassembly buffer and proceed to or remain in the REASS state. 
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If the CPCS receiver receives a SAR-U-Abon-signal or a SAR-P-Abort-signal primitive from the SAR 
sublayer while in the IDLE state, the primitive shall be ignored; when in the REASS state, the CPCS 
receiver shall free the reassembly buffer and proceed to the IDLE state. 

If the CPCS receiver is in the ABORT state and it receives a SAR-UNITDATA-signal primitive with the 
M parameter set to "1", the primitive shall be ignored and the CPCS receiver shall remain m the ABORT 

state. 

However if in the ABORT state the CPCS receiver receives a SAR-U-Abort or SAR-P-Abort-signal 
primitive or a SAR-UNITDATA-signal primitive with the M parameter set to "Or, the CPCS receiver 
shall proceed to the IDLE state. 

4.4.3 Procedures of the CPCS for the streaming mode service 

These procedures are for further study. 

4.4.4 Procedures of the SSCS 
These procedures are for further study. 

5 AAL type 4 

As the enhanced specification for AAL types 3 and 4 are now equivalent, the texts have been merged into 4 and referred 
to as AAL type 3/4. 

See 4. 



6 AAL type 5 

Under study. 
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6 AAL type 5 



6.0 Framework of AAL type 5 



The Convergence Sublayer (CS) has been subdivided into the Common Part CS (CPCS), and the Service Specific CS 
(SSCS) as shown in Figure 6-1. Different SSCS protocols, to support specific AAL user services, or groups of services, 
may be defined. The SSCS may also be null, in the sense that it only provides for the mapping of the equivalent 
primitives of the AAL to CPCS and vice versa. SSCS protocols are specified in separate Recommendations. 



SAP 



Service Specific CS 
(maybe mil) 

~~K 



Primitives 



Common Part CS 

r 



Primitives 



SAR 



SAP 
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FIGURE 6-1/1.363 
Structure of the AAL type 5 



6*1 Service provided by the AAL type 5 



The AAL type 5 provides the capabilities to transfer the AAL-SDU from one AAL user to another AAL user through the 
ATM network. The Message Mode service. Streaming Mode service, and assured and non-assured operations as defined 
below for AAL type 5 are identical to those defined for AAL type 3/4 in 4.1. 



Two modes of service are defined: Message and Streaming. 



a) Message Mode service - The AAL Service Data Unit is passed across the AAL interface in exactly one 
AAL Interface Data Unit (AAL-IDU). This service provides the transport of fixed size or variable length 
AAL-SDUs. 

i) In case of small fixed size AAL-SDUs, an internal blocking/deblocking function in the SSCS may be 
applied; it provides the transport of one or more fixed size AAL-SDUs in one SSCS-PDU. 

ii) In case of variable length AAL-SDUs, an internal AAL-SDU message segmentation/reassembling 
function in the SSCS may be applied. In this case a single AAL-SDU is transferred in one or more 
SSCS-PDUs. 



iii) Where the above options are not used, a single AAL-SDU is transferred in one SSCS-PDU. When 
the SSCS is null, the AAL-SDU is mapped to one CPCS-SDU. 
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b) Streaming Mode service - The AAL-SDU is passed across the AAL interface in one or more AAL-IDU 
£13* of these AAL-IDUs across the AAL interface may occur separated in ume. Th.s service 
provides the transport of variable length AAL-SDUs. The Streaming Mode service includes an abort 
se^cfby which Ihe discarding of an AAL-SDU partially transferred across the AAL interface can be 
requested. 

i) An internal AAL-SDU message segmenUrion/reassembling function in the SSCS may be applied. In 
ttacSe all the AAL-IDU? belonging to a single AAL-SDU are transferred in one or more 
SSCS-PDU. 

ii) An internal pipelining function may be applied. It provides the means by which the «nding AAL 
entity initiates the transfer to the receiving AAL entity before it has the complete AAL-SDU 
available. 

iii) Where option i) is not used, all the AAL-IDUs belonging to a single AAI.SDU are t^ferred m 
one SSCS-PDU. When the SSCS is null, the AAL-IDUs belonging to a smgle AAL-SDU are 
mapped to one CPCS-SDU. 

Summaries of the service mode and feature options are provided in Table 6- 1 and Table 6-2. 



TABLE 6-1/L363 



Combination of service mode and internal functions 





AAL-SDU message segmentation/ 
reassembly 
in the SSCS 


AAL-SDU 
blocking/deblocking 
in the SSCS 


Pipelining 


Message 

Option 1 
Option 2 


O 

N/A 


N/A 
0 


N/A 
N/A 


Streaming 


0 


N/A 


0 


Option 1 Long variable size S 
Option 2 Short fixed size SDl 
O Optional 
N/A Not Applicable 


DUs 
Is 



TABLE 6-2/1.363 



Combination of service mode at the sender and receiver side 





Sender 






MM/Block 


MM/Seg 


SM 


MM/Deblocking 


A 


N/A 


N/A 


MM/Reassembiy 


N/A 


A 


A 


SM 


N/A 


A 


A 


MM Message Mode 
SM Streaming Mode 
A Applicable 
N/A Not Applicable 

NOTE - An end-to-end spec 


ification of the SDU length in Message Mode with Blwtog^eblocking is needed. 
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Both modes of service may offer the following peer-to-peer operational procedures: 



Assured operations 



Every assured AAL-SDU is delivered with exactly the data content that the user sent The assured service 
is provided by retransmission of missing or corrupted SSCS-PDUs. Flow control is provided as a, 
mandatory feature. The assured operation may be restricted to point-to-point ATM Adaptation Layer 
connections. 

Non-assured operations 

Integral AAL-SDUs may be lost or corrupted. Lost and corrupted AAL-SDUs will not be corrected by 
retransmission. An optional feature may be provided to allow corrupted AAL-SDUs to be delivered to the 
user (i.e. optional error discard). Flow control may be provided as an option. 



6.1.1 Description of AAL connections 

The AAL type 5 provides the capabilities to transfer the AAL-SDU from one AAL-SAP to one other AAL-SAP through 
the ATM network [see Figure 6.2a)]. The AAL users will have the capability to select a given AAL-SAP associated with 
the QOS required to transport the AAL-SDU (for example, delay and loss sensitive QOS). 

The AAL type 5 in non-assured operation provides the capability to transfer the AAL-SDUs from one AAL-SAP to 
more than one AAL-SAP through the ATM network [see Figure 6.2b)]. 

The AAL type 5 makes use of the service provided by the underlying ATM layer [see Figure 6.3]. Multiple AAL 
connections may be associated with a single ATM layer connection, allowing multiplexing at the AAL; however, if 
multiplexing is used in the AAL, it occurs in the SSCS. The AAL user selects the QOS provided by the AAL through 
the choice of the AAL-SAP used for data transfer. 



6.1*2 Primitives 

The functional model for AAL type 5 as contained in Annex E shows the interrelation between the SAR, CPCS and 
SSCS and the SAR and CPCS primitives. 

6.1.2.1 Primitives for the AAL 

These primitives are service specific and are contained in separate Recommendations on SSCS protocols. 

The SSCS may be null, in the sense that it only provides for the mapping of the equivalent primitives of the AAL to 
CPCS and vice versa. In this case, the primitives for the AAL are equivalent to those for the CPCS (see 6.1.2.2) but 
identified as AAL-UNITDATA request, AAL-UNITDATA indication, AAL-U-ABORT request, AAL-U- ABORT 
indication and AAL-P-ABORT-indication, consistent with the primitive naming convention at an SAP. 

6.1 J.2 Primitives for the CPCS of the AAL 

As there exists no Service Access Point (SAP) between the sublayers of the AAL type 5, the primitives are called 
"invoke" and "signal" instead of the conventional "request" and "indication" to highlight the absence of the SAP. 

6.1.2.2.1 Primitives for the data transfer service 

These primitives are CPCS-UNITDATA invoke and the CPCS-UNTTDATA signal. They are used for the data transfer. 
The following parameters are defined: 

- Interface Data (ID) 



This parameter specifies the interface data unit exchanged between the CPCS and the SSCS entity. The 
interface data is an integral multiple of one octet If the CPCS entity is operating in the Message Mode 
service, the Interface Data represents a complete CPCS-SDU; when operating in the Streaming Mode 
service, the Interface Data does not necessarily represent a complete CPCS-SDU. 



9 



- More(M) 



In the Message Mode service, this parameter is not used. In the Streaming Mode service, this parameter 
specifies whether the Interface Data communicated contains a beginning/continuation of a CPCS-SDU or 
the end of/complete CPCS-SDU. 
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NOTES 

1 If multiplexing is present at the AAL, it occurs in the SSCS. 

2 How QOS at the AAL-SAP is mapped to the ATM-SAP QOS in the event of multiplexing in the 
AAL is for further study. 

FIGURE 6-3/1.363 
Relation between AAL-SAP and ATM-SAP 



- CPCS-Loss Priority (CPCS-LP) 

This parameter indicates the loss priority for the associated CPCS-SDU. It can take only two values, one 
for high priority and the other for low priority. The use of this parameter in Streaming Mode is for further 
study. This parameter is mapped to and from the SAR-LP parameter. 

- CPCS Congestion Indication (CPCS-CI) 

This parameter indicates whether the associated CPCS-SDU has experienced congestion. The use of this 
parameter in Streaming Mode is for further study. This parameter is mapped to and from the SAR-CI 
parameter. 

- CPCS User-to- User indication (CPCS- UU) 

This parameter is transparently transported by the CPCS between peer CPCS users. The use of this 
parameter in Streaming Mode is for further study. 

- Reception Status ( RS) 

This parameter indicates that the associated CPCS-SDU delivered may be corrupted. This parameter is 
only utilized if the corrupted data delivery option is used. The use of this parameter in Streaming Mode is 
for further study. 

Depending on the service mode (Message or Streaming Mode service, discarding or delivery of errored information), not 
all parameters are required. This is summarized in Table 6-3. 

6,1.2.2.2 Primitives for the abort service 

These primitives are used in the Streaming Mode service. 

a) CPCS-U-ABORT invoke and CPCS V ABORT signal 

This primitive is used by the CPCS user to invoke the abort service. It is also used to signal to the CPCS 
user that a partially delivered CPCS-SDU is to be discarded by instruction from its peer entity. No 
parameters are defined. 

This primitive is not used in Message Mode. 

b) CPCS-P-ABORT signal 

This primitive is used by the CPCS entity to signal to its user that a partially delivered CPCS-SDU is to 
be discarded due to the occurrence of some error in the CPCS or below. No parameters are defined. 

This primitive is not used in Message Mode. 
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TABLE 6-3/1.363 
Parameters of the CPCS-UNITDATA 



Parameter 


Type 


MM 


SM 


Comments 


Interface Data (ID) 


Invoke 
Signal 


m 
m 


m 
m 


Whole or partial CPCS-SDU 


More (M) 


Invoke 
Signal 




m 
m 


M = 0:cnd of CPCS-SDU 
M = I: not end of CPCS-SDU 


CPCS -Loss Priority 


Invoke 
Signal 


m 
m 


FFS 
FFS 


Mapped to and from the ATM layer's CLP 
field 

CPCS-LP=1: Low Priority 
CPCS-LP=0: High Priority 


CPCS - Congestion 
Indication (CPCS-CI) 


Invoke 
Signal 


m 
m 


FFS 
FFS 


Mapped to and from tne aim layer s 
congestion indication parameter, 
CPCS-CI=1: congestion 
experienced; 

CPCS-CI=0: no congestion experienced 


CPCS - User-to-User 
Indication (CPCS-UU) 


Invoke 
Signal 


m 
m 


FFS 
FFS 


Transparently transported by the CPCS 


Reception status 
(RS) (Note 1) 


Invoke 
Signal 


m 


FFS 


Indication of corrupted data 



MM Message Mode service 
SM Streaming Mode service 

FFS The use of these parameters in Streaming Mode is for further study 
m Mandatory 
Not present 

NOTE - Not present if the corrupted data delivery option is not supported 



6.1.23 Primitives for the SAR sublayer of the AAL 

These primitives model the exchange of information between the SAR sublayer and the CPCS. 

As there exists no Service Access Point (SAP) between the sublayers of the ^AAL «. ^^^^ called 
invoke" and "signal" instead of the conventional "request" and "indication" to highlight the absence of the SAP. 

6,1,2.31 Primitives for the data transfer service 

These primitives are SAR-UNTTDATA-invoke and the SAR-UNTTDATA signal. They are used for the data transfer. 
The following parameters are defined: 

- Interface Data (ID) 

This parameter specifies the Interface Data unit exchanged between the SAR and the CPCS entit^The 
Sc^Data is\n integral multiple of 48 octets. The Interface Data does not necessarily represent a 
complete SAR-SDU. 

- More(M) 

This parameter specifies whether the Interface Data communicated contains the end of the SAR-SDU. 

- SAR-Loss Priority (SAR-LP) 

This parameter indicates the loss priority for the associated SAR Interface Data. It <^ take only two 
values, one for high priority, and the other for low priority. This parameter is mapped to the ATM layers 
Submitted Loss Priority parameter and from the ATM layer's Received Loss Priority parameter. 
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- SAR-Congestion Indication (SAR-C1) 

This parameter indicates whether the associated SAR Interface Data has experienced congestion. This 
parameter is mapped to and from the ATM layer's Congestion Indication parameter. 



6.2 Interaction with the management and control plane 

6*2.1 Management plane 

For further study. 
6.2.2 Control plane 
For further study. 



6.3 Functions, structure and coding of AAL type 5 
6.3.1 Segmentation and Reassembly (SAR) sublayer 
6J.1.1 Functions of the SAR sublayer 

The SAR sublayer functions are performed on an SAR-PDU basis. The SAR sublayer accepts variable length 
SAR-SDUs which are integral multiples of 48 octets from the CPCS and generates SAR-PDUs containing 48 octets of 
SAR-SDU data. 

a) Preservation of SAR-SDU 

This function preserves the SAR-SDU by providing for an "end of SAR-SDIT indication. 

b) Handling of congestion information 

This function provides for the passing of congestion information between the layers above the SAR 
sublayer and the one below in both directions. 

c) Handling of loss priority information 

This function provides for the passing of cell loss priority information between the layers above the SAR 
sublayer and the one below in both directions, 

6J.L2 SAR-PDU structure and coding 

The SAR sublayer function utilizes the ATM-layer-user to ATM-layer-user (AUU) parameter of the ATM layer 
primitives (the relationship between the AUU parameter and the ATM layer PIT encoding is defined in 2.2.4/1.361) to 
indicate that an SAR-PDU contains the end of an SAR-SDU. An SAR-PDU where the value of the AUU parameter is 
M P indicates the end of an SAR-SDU; the value of "0" indicates the beginning or continuation of an SAR-SDU. The 
structure of the SAR-PDU is illustrated in Figure 6-4. 







Cell Header j^J 

l 1 


SAR-PDU Payioad 




4 


SAR-PDU 


» 



T1300090-03M53 

PT» Payioad Type 



NOTE - The Payioad Type field belongs to the ATM header. It conveys the value of the AUU parameter 
end-to-end. 



FIGURE 6-4/1.363 
SAR-PDU format for tbe AAL type 5 
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632 Convergence Sublayer (CS) 

6.3.2.1 Functions, structure and coding for the CPCS 

The CPCS has the following service characteristics. 

- Non-assured data transfer of user data frames with any length measured in octetsfrom 1 to 65 535 octets. 
In addition, an independent octet of user-to-user information per frame is transferred. 

- The CPCS connection will be established by management or by the control plane. 

- Error detection and indication (bit error or cell loss or gain). 
_ CPCS-SDU sequence integrity on each CPCS connection. 

63.2.1.1 Functions of the CPCS 

The CPCS functions are performed per CPCS-PDU. The CPCS provides several functions in support of toe CPCS 
sertiSSr The functionfprovided depend on whether the CPCS service user is operating in Message or Streaming 
Mode. 

i) Message Mode service - The CPCS-SDU is passed across the CPCS interface in exactly one CPCS-IDU. 
This service provides the transport of a single CPCS-SDU in one CPCS-PDU. 

ii) Streaming Mode service - The CPCS-SDU is passed across the CPCS-interface in one 

° mus. The transfer of these CPCS-IDUs across the CPCS interface may ^S^^!!^ 
service provides the transport of all the CPCS-IDUs belonging to a single CPCS-SDU into one CPCS- 
roU M internal pipelining function in the CPCS may be applied which provides the means by which 
te sen^ng Scsity initiates the transfer to the receiving CPCS-entity before it h* . the compete 
oSSS arable. The Streaming Mode service includes an abort service by which the discarding of a 
CPCS-SDU partially transferred across the interface can be requested. 
NOTE - At the sending side, parts of the CPCS-PPU may have to be buffered if the restriction ("Interface Data are a 
multiple of 48 octets", see 6.3.1. 1) cannot be satisfied. 

The functions implemented by the CPCS include: 

a) Preservation of CPCS-SDU 

This function provides for the delineation and transparency of CPCS-SDUs. 

b) Preservation of CPCS user-to-user information 

This function provides for the transparent transfer of CPCS user-to-user information. 

c) Error detection and handling 

This function provides for the detection and handling of CPCS-PDU corruption Corrupted CPCSOTJJs 
Neither discarded or are optionally delivered to the SSC* The procedure for ^rfconupt^ 
CPCS-SDUs are for further study. When delivering errored information to the CPCS user, an error 
indication is associated with the delivery. 

Examples of detected errors would include: received length and CTCS-PDU Length field mismatch 
Sduding buffer overflow, and improperly formatted CPCS-PDU and CPCS CRC errors. 

d) Abdrt 

This function provides for the means to abort a partially transmitted CPCS-SDU. This function is 
indicated in the Length field. 

e) Padding 

A padding function provides for 48 octet alignment of the CPCS-PDU trailer. 

f) Handling of congestion information 

This function provides for the passing of congestion information between the layers above the CPCS and 
the one below in both directions. 
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g) Handling of loss priority information 



This function provides for the passing of cell loss priority information between the layers above the CPCS 
and the one below in both directions. 

Other functions are for further study. 
6.3.2.1.2 CPCS structure and coding 

The CPCS functions require an 8 octet CPCS-PDU trailer. The CPCS-PDU trailer is always located in the last 8 octets of 
the last SAR-PDU of the CPCS-PDU. Therefore, a padding field provides for a 48-octet alignment of the CPCS-PDU. 
The CPCS-PDU trailer together with the padding field and the CPCS-PDU payload comprise the CPCS-PDU. The sizes 
and positions of fields for the CPCS-PDU structure are given in Figure 6-5. 



CPCS-PDU paytoad (CPCS-SDU) 




I'll' 



CPCS-POU 
trailer 



CPCS-UU 


CPI 


1 

Length 


CRC 


CPCS-PDU trailer 

« ► 



CPCS-PDU 

Tt300100-93MS4 



PAD Padding (0 ... 47 octets) 

CPCS-UU CPCS User-to-User Indcatton (1 octet) 

CPt Common Part Indicator (1 octet) 

Length Length of CPCS-SDU (2 octets) 

CRC Cyclic Redundancy Check (4 octets) 



FIGURE 6-5/1.363 
CPCS-PDU Format for the AAL type 5 



The coding of the CPCS-PDU conforms to the coding conventions specified in 2-1/L361. 

a) CPCS-PDU payload 

The CPCS-PDU payload is used to carry the CPCS-SDU. This field is octet aligned and can range from 
1 to 65 535 octets in length. 

b) Padding (PAD) field 

Between the end of the CPCS-PDU payload and the CPCS-PDU trailer, there will be from 0 to 47 unused 
octets. These unused octets are called the Padding (PAD) field; they are strictly used as filler octets and 
do not convey any information. Any coding is acceptable. This padding field complements the 
CPCS-PDU (including CPCS-PDU payload, padding field, and CPCS-PDU trailer) to an integral multiple 
of 48 octets. 

The function of the PAD field is shown in Figure 6-6. 

c) CPCS User-to-User indication (CPCS-UU) field 

The CPCS-UU field is used to transparently transfer CPCS user-to-user information. 
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FIGURE 6-671.363 
Examples of the PAD field function 
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d) Common Part Indicator (CPl) field 

One of the functions of the CPI field is to align the CPCS-PDU trailer to 64 bits. Other functions are for 
further study. Possible additional functions may include identification of layer management messages. 
When only die 64-bit alignment function is used, this field shall be coded as zero. Other codings are for 
further study. 

e) Ungthfield 

The Length field is used to encode the length of the CPCS-PDU payload field. The Ungth field value is 
also used by die receiver to detect the loss or gain of information. 

The length is binary encoded as number of octets. 

A Length field coded as zero is used for the abort function. 

f) CRCfield 

The CRC-32 is used to detect bit errors in the CPCS-PDU. 

The CRC field is filled with the value of a CRC calculation which is performed over the entire contents of 
the CPCS-PDU, including the CPCS-PDU payload, the PAD field, and the first four octets of the 
CPCS-PDU trailer. The CRC field shall contain the ones complement of the sum (modulo 2) of: 

1) the remainder of x* ■ (x* + x*> + ...x + 1) divided (modulo 2) by the generator polynomial, where k 
is the number of bits of the information over which the CRC is calculated; and 

2) the remainder of the division (modulo 2) by the generator polynomial of the product of x 32 by the 
information over which the CRC is calculated. 

The CRC-32 generator polynomial is: 

000 = x 32 + x 26 + x 23 + x 22 + x 16+ x 12 + x ll + x 10 + x » + x 7 + x 5 + x4 + x 2 + x+ i 
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The result of the CRC calculation is placed with the least significant bit right justified in the CRC 
field. 

As a typical implementation at the transmitter, the initial content of the register of the device 
computing the remainder of the division is preset to all "Is" and is then modified by division by the 
generator polynomial (as described above) on the information over which the CRC is to be 
calculated; the ones complement of the resulting remainder is put into the CRC field. 

As a typical implementation at the receiver, the initial content of the register of the device computing 
the remainder of the division is preset to all "Is". The final remainder, after multiplication by x 32 and 
then division (modulo 2) by the generator polynomial of the serial incoming CPCS-PDU, will be (in 
the absence of errors): 



C(x) = x 31 + x 30 +x 26 +x 25 + x 24 +x 18 +x 15 + x 14 +x 12 + x 1 Ux I0 +x 8 +x 6 +x 5 + x 4 + x 3 +x+t 
An example of the CRC calculation is given in Appendix m. 



6.4 Procedures 

6.4.1 Procedures for the SAR sublayer 

The structure and coding of the SAR-PDU is defined in 6.3.1.2. 

6.4.1.1 State variables of the SAR sublayer at the sender side 
The SAR sender maintains no state variables. 

6.4.1.2 Procedures of the SAR sublayer at the sender side 
The state machine of the SAR sender is shown in Figure 6-7. 




SAR-UNfTDATA Invoke 



FIGURE 6-7/1.363 
State transition diagram for the SAR sender 



Table 6-4 defines the state for the SAR sender. 



TABLE 6-4/1.363 



State definition for the SAR sender 



State 



Definition 



IDLE 



Waiting to begin or continue to transmit a SAR-SDU 



Recommendation L363 (11/93) 37/11 



COPYRIGHT International Telecommunications Union /ITU Telecommunications 



ITU 



ECf1N*I.3b3 



It S7T 



1) Upon receiving a SAR-UNTTDATA invoke primitive from the CPCS, the SAR sender shall start the 
segmenting process. If the interface data has a length of more than 48 octets, the SAR sender will 
generate more than one SAR-PDU. In all SAR-PDUs, the SAR-PDU payload field shall be filled with 
48 octets of CPCS-PDU information. 

2) If the More parameter in the SAR-UNTTDATA invoke primitive has the value *W\ the SAR sender shall 
set the AUU parameter in the ATM-DATA request primitive for the last SAR-PDU generated from the 
interface data to "1"; in all other cases (i.e. the More parameter has the value "1" or the ATM-DATA- 
request primitive does not contain the last data generated from the interface data), it shall set the AUU 
parameter to 14 0". 

3) In all ATM-DATA request primitives, the "Submitted CLP" and "Congestion Indication" parameters 
shall be set to the same value as the SAR-LP and SAR-CI parameters, respectively, in the received 
SAR-UNTTDATA invoke primitive. 

6.4.13 State variables for the SAR sublayer at the receiver side 

The SAR receiver maintains no state variables. 

6.4.1.4 Procedures of the SAR sublayer at the receiver side 

The state machine of the SAR receiver is shown in Figure 6-8. 




ATM-DATA Indication 



T130013043M57 



FIGURE 6-8/1.363 
State trandtJoo diagram for the SAR receiver 



Table 6-5 defines the state for the SAR receiver. 



TABLE 6-5/1.363 
State definition for the SAR receiver 



State 


Definition 


IDLE 


Waiting to begin or continue to receive a S AR-SDU 



1) Upon receipt of an ATM-DATA indication primitive, the 48 octet SAR-PDU payload is sent to the CPCS. 
If the AUU parameter in the ATM-DATA indication primitive is set to "1", the More parameter is set to 
'V; otherwise, the More parameter is set to "P. 
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2) In all SAR-UNTTDATA signal primitives, the SAR-CI and the SAR-LP parameters shall be set to the 
same value as the Congestion Indication" and the "Received Loss Priority" parameters, respectively, in 
the received ATM-DATA indication primitive. 

6.4.2 Procedures of the CPCS for the message mode service 

The structure and coding of the CPCS-PDU is defined in 6.3.2.1.2. 

6.4.Z1 State variables of the CPCS at the sender side 

The CPCS- sender maintains no state variables. 

6.4.12 Procedures of the CPCS at the sender side 

The state machine of the CPCS sender is shown in Figure 6-9. 




FIGURE 6-9/1.363 
State transition diagram for the CPCS sender 



Table 6-6 defines the state for the CPCS sender. 



TABLE 6-6/1.363 
State definition for the CPCS sender 



State 


Definition 


IDLE 


Waiting to transmit a new CPCS-SDU 



Upon reception of a CPCS-UNITDATA invoke primitive, the CPCS-PDU is constructed as described in 6.3.2.1.2, and 
the CPCS-PDU is passed to the SAR sublayer in a SAR-UNTTDATA invoke primitive with the More parameter set to 
"0". The SAR-LP and the SAR-CI parameters are set to the value of the CPCS-LP and the CPCS-CI parameters, 
respectively, of the CPCS-UNITDATA invoke primitive. The CPCS-UU field is assigned the value of the CPCS-UU 
parameter. 

6.4.23 State variables of the CPCS at the receiver side 

The CPCS receiver maintains the following state variable: 
- rcv_LP 

The rcvJLP variable is initially set to zero. If any SAR-LP parameter is set to one, this variable is set to 
one. It is used to set the CPCS-LP parameter in the CPCS-UNITDATA signal primitive. 
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d.4,2.4 Procedures of tbeCPCS at the receiver side 

The following procedures are specified for a CPCS receiver that does not deliver errored data to the receiving CPCS 
user. Optional delivery of errored information is for further study. 

The CPCS receiver maintains the following parameter: 
- Max_SDUJ)eliver__Length 

This parameter indicates the maximum size SDU, in octets that may be delivered to a CPCS user. At a 
SeivTSe value of this parameter is compared to the length of each CPCS-SDU before U is .delivered 
Any CPCS-SDUs that have a length greater than Max.SDU.Deliver^ngth are d^carded and Ae even 
is reported to Layer Management This parameter can take on any integer value from 1 to 65 535 and is 
set by the management plane. 

The state machine of the CPCS receiver is shown in Figure 6-10. 




FIGURE 6-KVL363 
State transition diagram for the CPCS receiver 



Table 6-7 defines the state of the CPCS receiver. 



TABLE 6-7/L363 
State definition for the CPCS receiver 



State 


Definition 


IDLE 


Waiting to begin or continue to receive a CPCS-SDU 



NOTE - This procedure description may copy up to 47 octets of the PAD field into the reassembly buffer before 
processing the CPCS-PDU trailer. 

n When the CPCS receiver receives a SAR-UNTTDATA signal primitive from the SAR sublayer, it shall 
° ^y the i^L^l to the reassembly buffer. If the SAR-LP parameter is set to one, the vanable 
rev _JJ> is also set to one. 

If the More oarameter of the SAR-UNTTDATA signal primitive is "1" and the received number of octets 
* n^^a^r buffer of the CPCS-SDU is greater than the value of the parameter 
^SDTrSvij.ength" plus 7. the CPCS receiver shall discard any information tn the reassembly 



buffer. 
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3) If the More parameter of the SAR-UNTTDATA signal primitive is t4 0'\ the last eight octets of the 
interface data represent the CPCS-PDU trailer. If the CRC calculation performed on the complete 
CPCS-PDU as specified in 6.3.2.1.2 and the value in the CRC field indicate the presence of errors, any 
information in the reassembly buffer shall be discarded. 

4) If the value in the CPI field is not valid, any information in the reassembly buffer shall be discarded. 

5) If the Length field of the CPCS-PDU trailer is coded as zero, any information in the reassembly buffer 
shall be discarded. 

6) The Length field of the CPCS-PDU trailer is used to determine the length of the PAD field (length of 
received CPCS-PDU minus eight and minus the content of the Length field). If the PAD field is longer 
than 47 octets or not enough data has been received, any information in the reassembly buffer shall be 
discarded. 

7) After the receipt of a SAR-UNTTDATA signal primitive with the More parameter set to "0" and the data 
has not been discarded, any CPCS-SDU data in the reassembly buffer shall be delivered to the CPCS user 
via a CPCS-UNITDATA signal primitive. The CPCS-LP parameter shall be set to the value of the 
variable rcv_LP. The CPCS-CI parameter shall be set to the value of the SAR-CI parameter received with 
the last SAR-UNTTDATA signal primitive. The CPCS-UU parameter shall be set to the value of the 
CPCS-UU field of the CPCS-PDU trailer. Data that is delivered is removed from the reassembly buffer. 

8) Whenever information from the reassembly buffer is delivered or discarded, the variable rcv_LP is reset 
to zero. 

If a reassembly timer is supported, the following procedures apply: 

9) When the CPCS receiver receives a SAR-UNTTDATA signal primitive from the SAR sublayer with the 
More parameter set to *T\ the reassembly timer shall be (re) started 

10) When the CPCS receiver receives a SAR-UNTTDATA signal primitive from the SAR sublayer with the 
More parameter set to "0", the reassembly timer shall be stopped. 

11) If the timer expires, the CPCS receiver shall discard any information in the reassembly buffer. 

Other reassembly timer procedures are for further study. 
NOTE - The timer value is not specified in this Recommendation. 

6.4*3 Procedures for the CPCS for the Streaming Mode service 

For further study. 

6.4.4 Summary of parameters and values for an AAL type 5 connection 

The information in Table 6-8 must be known at AAL type 5 connection establishment 



TABLE 6-8/1.363 



Parameters and options for the AAL type 5 



Significance 


Option/parameter 


Value/Range 


Peer-to-peer 


Max_SDUJ)eliver_Length 


1 to 65 535 octets 


Local 
(receiver) 


Corrupted SDU delivery 


No/yes 


Use and value of reassembly timer 


No/yes-and value 
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Annex A 



Details of the data unit naming convention 

(This annex forms an integral part of this Recommendation) 



Details of the data unit naming convention are given in Figures A. 1 to A.3. 



AAL-SAP 







AAL-SDU 




Convergence 
sublayer (CS) 


CS-PDU 


CS-PDU paytoad 


CS-PDU 
trailer 



CO 

o 



CS-PDU 



No SAP defined between CS and SAR 



Segmentation 

and reassembly (SAR) 

sublayer 



SAR-PDU 


SAR-PDU 


SAR-PDU 


header 


paytoad 


trailer 


< 


SAR-PDU 


► 



i 



ATM-SAP 



ATM-SDU 



ATM 
layer 



Cell 
header 



Cell information field 
(cell paytoad) 



ATM-PDU = Cell 



t 



T1817750-92/d21 



NOTES 



1 ATM adaptation layer-protocol control information ( AAL-PCI) consists of the SAR-PDU Header, 
CS-PDU header, CS-PDU trailer, and SAR-PDU trailer. 

2 The figure is to indicate the naming of the AAL data units only. It is not implied that all fields are 
present in all cases. See Annex D for a list of abbreviations. 



FIGURE A. 1/1.363 
General data unit naming conventions 
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Service specific 
convergence 
sublayer (SSCS) 



Common part 
convergence 
sublayer (CPCS) 



Segmentation 

and reassembly (SAR) 

Sublayer 



AAL-SAP 



(Note 2) 



AAL-SDU 



SSCS-PDU 
header 



SSCS-PDU payioad 



SSCS-PDU 
trailer 



CO 



SSCS-PDU 



No SAP defined between SSCS and CPCS 



CPCS-SDU 



CPCS-PDU 
header 



CPCS-PDU paytoad 



CPCS-PDU 
trailer 



CPCS-PDU 



No SAP defined between CPCS and SAR 



SAR-PDU 


SAR-PDU 


SAR-PDU 




paytoad 


trailer 



SAR-PDU 



ATM-SAP 



3 



ATM-SDU 



ATM 
layer 



Cell 
header 



Cell information field 
(cell payioad) 



ATM-PDU=Cell 



T1817760-92/d22 



NOTES 

1 The figure is to indicate the naming of the AAL data units only. It is not implied that all fields are 
present in all cases. See Annex D for a list of abbreviations. 



2 The exact structure of the SSCS-PDU is for further study. 



FIGURE A.2/I.363 
Data unit naming conventions of the ALL type 3/4 
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a) Message mode service 



AAL-SDU 



AAL-SDU 
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AAL interface 
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b) Message mode service plus blocking/deblocking Internal function 
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c) Message mode service plus segmentation/reassembly Internal function 



FIGURE A.3/L363 (sheet 1 of 2) 
Message and streaming mode of service at the AAL type 3/4 Interface combined with 
blocking/deblocking or segmentation/reassembly internal function 
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d) Streaming mod* service 
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FIGURE A.3/L363 (sheet 2 of 2) 
Message and streaming mode of service at the AAL type 3/4 Interface combined with 
blocking/deblocking or segmentation/reassembly internal function 
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FIGURE A.4/L363 
Data unit naming conventions for the AAL type 5 
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Annex B 

General framework of the AAL type 3/4 

(This annex forms an integral pan of this Recommendation) 



This annex provides a description of the general framework of the AAL type 3/4 including SAR and CPCS PDU 
formats. 

B.l Message segmentation and reassembly 

Figure B.l provides a generic interpretation of the segmenting of a message into beginning of message (BOM), 
continuation of message (COM) and end of message (EOM). Short messages are represented as a single segment 
message (SSM). 



SAR-SOU (message) 



BOM 
"segment* 



COM 
"segment" 



COM 
"segmenT 



EOM 
"segment* 



T1817790-92/d25 



FIGURE B. 1/1.363 
Message segmentation and reassembly 



B.2 PDU headers, trailers and terminology 

Figure B.2 builds on the generic view of message segmentation of Figure B.l to incorporate the relevant PDU headers 
and trailers and appropriate terminology on the basis of BOM, COM and EOM which is of particular relevance to the 
combined SAR and CPCS-PDU formats of Figure B.3 
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FIGURE B.2/I.363 
PDU headers, trailers, and terminology 



B.3 SAR and CPCS format 

Figure B.3 illustrates the combined SAR and CPCS PDU format on a segment by segment basis. 
The definition of the encoding and functions associated with the fields is described in 4.3.1.2 and 
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MID Multiplexing Identification BAsize Buffer aflocatton size 
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CRC Cyclic redundancy check Length CPCS-PDU paytoad length 

CPI Common part indicator 

FIGURE B.3/L363 
Combined SAR and CPCS-PDU format 
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B.4 Relation of the MID field to the SN field and Btag/Etag fields 

As an example, the following Figure B.4 illustrates the possible relation of the MID field values to the SN field and 
Btag/Etag field values for the AAL type 3/4. 
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NOTE - Modulo 16 and modulo 256 apply to determine the SN field and the Btag/Etag fields. 

FIGURE B.4/L363 

The relation of MID field values to the SN field and 
Btag/Etag field values for AAL type 3/4 



B.5 Examples of the segmentation and reassembly process 

The Figure B.5 shows schematically a successful segmentation and reassembly of a CPCS user PDU in message mode. 
In Figure B.6, a SAR-PDU is assumed lost due to a transmission error, hence, the reassembly cannot be completed. 
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FIGURE BJ/I.363 
Successful segmentation and reassembly of a CPCS user PDU 
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FIGURE B.6/I.363 
Segmentation and unsuccessful reassembly of a CPCS user PDU 
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Annex C 



Functional model for the AAL type 3/4 

(This annex forms an integral part of this Recommendation) 



For the AAL type 3/4, the functionality of the SSCS may provide only for the mapping of the equivalent primitives of 
the AAL to the CPCS and vice versa. The SSCS may also implement functions such as assured data transfer, etc. Such 
functions* however, are not shown in the following figures. 

The functional model of the AAL type 3/4 at the sender side is shown in Figure C.l. The model consists of several 
blocks that cooperate to provide the AAL type 3/4 services. Each SAR and CPCS block that are paired represent one 
segmentation state machine. 

The interleaver allocates the available bit rate of the ATM connection to the SAR-PDUs generated by the segmentation 
state machines according to some internal policy. 

The functional model of the AAL type 3/4 at the receiver side is shown in Figure C.2. The model consists of several 
blocks that cooperate to provide the AAL type 3/4 services. Each SAR and CPCS block that are paired represnet one 
reassembly state machine. The dispatcher (R_DSP) routes the primitives from the ATM layer to the appropriate 
reassembly state machine based on the value of the MID field within the SAR-PDU. 
NOTE - Layer management interactions require further study. 
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FIGURE C. 1/1.363 
Functional model for the AAL Type 3/4 (Sender side) 
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FIGURE C.2/L363 
Functional model for the AAL Type 3/4 (Receiver side) 
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Annex D 

Alphabetical list of abbreviations used in this Recommendation 

(This annex forms an integral part of this Recommendation) 



AAL ATM adaptation layer 

AAL-IDU AAL interface data unit 

AAL-SDU AAL service data unit 

ATM-SDU ATM service data unit 

BOM Beginning of message 

COM Continuation of message 

CPCS Common part convergence sublayer 

CPCS-PDU CPCS protocol data unit 

CPCS-SDU CPCS service data unit 

CRC Cyclic redundancy check 

CS Convergence sublayer 

CS-PDU CS protocol data unit 

CSI Convergence sublayer indication 

EOM End of message 

FEC Forward error correction 

LSB Least significant bit 

M More 

MID Multiplexing identification 

MSB Most significant bit 

OAM Operation Administration maintenance 

RTS Residual time stamp 

SAP Service access point 

SAR Segmentation and reassembly sublayer 

S AR-PDU SAR protocol data unit 

SAR-SDU SAR service data unit 

SDT Structure data transfer 

SNP Sequence number protection 

SRTS Synchronous residual lime stamp 

SSCS Service specific convergence sublayer 

SCS-PDU SSCS protocol data unit 

SSM Single segment message 
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Annex E 

Functional model for the AAL type 5 

(This annex forms an integral part of this Recommendation) 



For the AAL type 5, the functionality of the SSCS may provide only for the mapping of the equivalent primitives of the 
AAL to the CPCS and vice versa. On the other hand, the SSCS may implement functions such as assured data transfer. 
Such functions, however, are not shown in the Figures E.1 and E.2. 

The functional model of the AAL type 5 at the sender side is shown in Figure E.l. The model consists of several blocks 
that cooperate to provide the AAL type 5 service. The SAR and CPCS blocks that are paired represent the segmentation 
state machine. 

The functional model of the AAL type 5 at the receiver side is shown in Figure E.2. The model consists of several 
blocks that cooperate to provide the AAL type 5 service. The SAR and CPCS blocks that are paired represent the 
reassembly state machine. 

NOTE - Layer management interactions require further study. 
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FIGURE E-1/L363 
Functional model for the AAL type 5 (sender side) 
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NOTE - Concerning the SSCS, the functional model is an example only. Possible functions in the 
SSCS (i.e. multiplexing) are not shown. The SSCS is specified in other Recommendations. 

FIGURE E-2/I.363 
Functional model for the AAL type 5 (receiver side) 
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Annex F 



General framework of the AAL type 5 

(This annex forms an integral part of this Recommendation) 

This annex provides a description of the general framework of the AAL type 5 including SAR and CPCS PDU formats. 
F.l Message segmentation and reassembly 

Figure F.l provides a generic interpretation of the segmenting of a SAR-SDU (message) into SAR-PDUs where the 
AUU bit in the header of the associated ATM-SDU is set to "0" and the last SAR-PDU where the AUU bit is set to "1". 
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• • • • 
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"segment" 
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FIGURE F- 1/1.363 
Message segmentation and reassembly 



F.2 PDU headers, trailers and terminology 

Figure F.2 builds on the generic view of message segmentation of Figure A.1 to incorporate the relevant PDU headers 
and trailers and appropriate terminology on the basis of the AUU bit being set to "0" or "1". 

¥3 Examples of the segmentation and reassembly process 

Figure F.3 shows schematically a successful segmentation and reassembly of a CPCS user PDU in message mode. 
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FIGURE F.2/L363 
PDU Headers, trailers and terminology 
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FIGURE F.3/L363 
Successful segmentation and reassembly of a CPCS user PDU 
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Appendix I 

SDL diagrams for the SAR and the CPCS of the AAL type 3/4 

(This appendix does not form an integral part of this Recommendation) 



1.1 SDL for the SAR sublayer 

The pin pose of this appendix is to provide one example of an SDL representation of the SAR procedures and with it to 
assist m the understanding of this Recommendation. This representation does not describe all of the possible actions of 
the SAR sublayer entity as a non-partitioned representation (i.e. the state machine is shown for one MID field value) was 
chosen in order to minimize its complexity. Therefore, the SDL representation does not constrain implementations from 
exploiting the full potential inherent in this highly parallel and fast environment. The text description of the procedures 
in the main part of this Recommendation is definitive. 

NOTE - The SDL diagrams in Figures 1. 1 and 1.2 represent the SAR for one MTD field value. 
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FIGURE 1. 1/1.363 (sheet 5 of 5) 
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FIGURE I.2/L363(sheet4of4) 



Ll.l The SAR sender 

The SAR sender makes use of the state variable snd_SN (as defined in 4.4.1.1). In addition, it utilizes four further 
variables: 

a) ptrPDU 

This is a temporary variable that points into the (partial) CPCS-PDU received via the SAR-UNITDATA- 
invoke primitive. As successive parts of the CPCS-PDU are filled into SAR-PDU payloads, this pointer 
keeps pointing at the first octet within the CPCS-PDU that has not yet been sent within a SAR-PDU. 

b) len 

This temporary variable is set to the length of the (partial) CPCS-PDU received via the 
S AR-UNITD ATA-invoke primitive. 

c) count 

This temporary variable keeps track of the number of octets still awaiting segmentation and transmission 
within a SAR-PDU. 

d) snd_ST 

This temporary variable is used to set the ST field of the SAR-PDU header. It can take the values: 
"BOM", "COM", "EOM" or "SSM". 

e) snd J41D 

This variable contains the value of the MID field that is put into every SAR-PDU. 
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The primitive MAAL-ID is used in the SAR sender. Its only parameter communicates a MID field value from layer 
management to the SAR sender. The details of this primitive and all other interactions with layer management are for 
further study. 

1.1.2 The SAR receiver 

The SAR receiver makes use of the state variable rcv_SN (as defined in 4.4.1.3). It utilizes no further variables. 
Ail illegal SAR-PDUs are ignored. An illegal SAR-PDU is a SAR-PDU with either 

a CRC verification error, or 

an unexpected MID field value. 
NOTES 

1 The discarding of illegal SAR-PDUs actually takes place prior to assigning the SAR-PDU to a reassembly process 
governed by a particular MID field value, hence, this is not shown in the SDL diagrams. 

2 No interactions with layer management are shown; these interactions require further study. 
L2 SDL for the common part CS (CPCS) procedures 

The purpose of this appendix is to provide one example of an SDL representation of the CPCS procedures and with it to 
assist in the understanding of this Recommendation. This representation does not describe all of the possible actions of 
the CPCS entity as a non-partitioned representation (i.e. the state machine is shown for one MID field value) was chosen 
in order to minimize its complexity. In particular, neither delivery of errored data nor streaming mode procedures are 
included. Therefore, the SDL representation does not constrain implementations from exploiting the full potential 
inherent in this highly parallel and fast environment. The text description of the procedures in the main part of this 
Recommendation is definitive. 

NOTE - The SDL diagrams of Figures 1.4 and 1.5 represent the CPCS for one MID field value. 

1.2.1 The CPCS sender 

The CPCS sender makes use of the state variable snd_BEtag (as defined in 4A2.1). In addition, it utilizes one further 
variable: 

len 

This temporary variable is set to the length of the interface data parameter received via the 
CPCS-UNITDATA-invoke primitive. It is used to set the BAsize field, the Length field, and to calculate 
the length of the PAD field. 

NOTE - No interactions with layer management are shown; these interactions require further study. 

1.2.2 The CPCS receiver 

The CPCS receiver makes use of the state variable rcvJBEtag and rcv_BAsize (as defined in 4.4.2.3). In addition, it 
utilizes three further variables: 

a) len 

This temporary variable is set to the length of the CPCS-PDU information received from the SAR 
sublayer for reassembly. 

b) reassembly buffer 

The reassembly buffer is allocated while processing the CPCS-PDU header and freed once the reassembly 
of a CPCS-PDU is complete (or abandoned due to errors). 

c) ptrRAB 

This variable points into the reassembly buffer to the octet where the next information received from the 
SAR sublayer is to be stored. 

NOTE - No interactions with layer management are shown; these interactions require further study. 
Figure 1.3 illustrates the use of the reassembly bu ffer during the reassembly of a CPCS-SDU. 
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FIGURE I.3/L363 
The mechanism of the reassembly buffer 
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Allocate RAS 
buffer size = 
rcv_BAs!ze 



The allocation of a reassembly buffer 
is implementation dependent. Some 
implementations may require a 
slightly larger reassembly buffer. 



ptrRAB = 0 



ptrSAR»4 
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Appendix II 

SDL diagram for the SAR and the CPCS of the AAL type 5 

(This appendix does not form an integral part of this Recommendation) 

IL1 SDL for the SAR sublayer 

The purpose of this subclause is to provide one example of an SDL representation of the SAR procedures, to assist in the 
understanding of this Recommendation. The SDL representation does not constrain implementations from exploiting the 
fiill potential inherent in this highly parallel and fast environment The text description of the procedures in the main 
body of this Recommendation is definitive. 

IL1.1 The SAR sender 

The SAR sender makes use of two variables: 

a) ptrPDU 

This is a temporary variable that points into the (partial) CPCS-PDU received via the SAR-UNTTDATA 
invoke primitive. As successive parts of the CPCS-PDU are filled into SAR-PDU payloads, this pointer 
keeps pointing at the first octet within the CPCS-PDU that has not yet been sent within an SAR-PDU. 

b) count 

This temporary variable keeps track of the number of octets still awaiting segmentation and transmission 9 
within an SAR-PDU. 

NOTE - No interactions with layer management are shown; these interactions require further study. 
IL1.2 The SAR receiver 

The SAR receiver maintains no variables. 

NOTE - No interactions with layer management are shown; these interactions require further study. 



IL2 SDL for the Common Part CS (CPCS) procedures 

The purpose of this subclause is to provide one example of an SDL representation of the CPCS procedures, to assist in 
the understanding of this Recommendation. Neither delivery of errored data nor Streaming Mode procedures are 
included. The SDL representation does not constrain implementations from exploiting the full potential inherent in this 
highly parallel and fast environment. The text description of the procedures in the main body of this Recommendation is 
definitive. 

O.Z1 The CPCS sender 

The CPCS sender maintains no variables. 

NOTE -r No interactions with layer management are shown; these interactions require further study. 

IL2.2 The CPCS receiver 

The CPCS receiver makes use of the state variable rcvJJ> (as defined in 6.4.2.3). In addition the CPCS receiver utilizes 
one variable: 

- reassembly buffer 

The reassembly buffer is allocated while processing the CPCS-PDU and freed once the reassembly of a 
CPCS-PDU is complete (or abandoned due to errors). 

NOTE - No interactions with layer management are shown; these interactions require farther study. 
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Prooets SAR Sender 



IDLE 




SAT-UNITDATA 
invoke 
(SAR-ID, M, 
SAR-LP, SAR-CI) 



ptrPDU :=0 



Whan submitting ATM- 
DATA request! 48 octets 
starting at ptrPDU wta 
be used In the ATM-ID. 



Count := 
length of SAR-tD 




ATM-DATA request 
(ATM- ID :« 46 octets 
staitlng at ptrPDU, 
AUU := 0,SLP:= SAR-LP, 
CI := SAR-CI) 



Yes 



ptrPDU := 
prtPDU + 48 



ATM-DATA request 
(ATM-ID :-480CtatB 
starting at ptrPDU, > 
AUU :=0,SLP:» SAR-IP, / 
CI := SAR-CI) / 



Count := 
Count -48 



ATM© AT A request 
(ATM-ID := 48 octets 
starting at ptrPDU, 
AUU := 1, SLP := SAR-LP, 
CI :» SAR-CI) 




IDLE 



Tl3001fr>9aMM 
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Process SAR Receiver 



IDLE 




ATM-DATA 
Indication 
(ATM-ID, AUU, 
RLP, CI) 



ATM-DATA signal 
(SAR-ID := ATM-ID, 
M := 0, SAR-LP := RLP, 
SAR-CI :=CI) 




SAR-UNITDATA signal 
(SAR-ID := ATM-ID, 
M:= 1, SAR-LP := RLP, 
SAR-CI := CI) 




IDLE 
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Process CPCS Sender 



IDLE 




CPCS-UNITDATA 
Invoke (CPCS-ID, 
CPCS-UU, CPCS-LP, 
CPCS-CI) 



Set PAD 



1 mo 



Length of PAD Is 47- 
((len3lh of CPCSHD + 7) 
mod 46) 



CPCS-UU fleW 
:= CPCS-UU 



Set CPt field 



The CPIftoW snail 
be sat to 0 



Ungt* fleU:= 
length of CPCS4D 



Compute CRC32 



Catenated over CPCS-PDU 
— I Inducting PAD and the first 
4cctetsof thetraler. 



4a 



SAR-UNTTDATA 
invoke (SAR-1D := 
CPCS-RDU,M:»0, 
SAR-LP:=CPCS-LP, 
SAR-CI := CPCS-CI) 




IDLE 
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Process CPCS Receiver 




rcv.LP := 0 



IDLE 



SAR-UWTDATA 
.slgwMSAR-IQ. 
>M,SAR-LP, 

SAR-Cf) 



Append SAR-ID to 
reassembly buffer 



rcvJP := 
rcv_LPorSAR-LP 



Free 
reassembly buffer 



rcvJ-P := 0 




Free 
reassembly buffer 



rev LP :=0 




Startfrestart 
RAS timer 



RAS timer 
expired 




[Hp to 7 octets of PAD 
No J Information may be carried 
" 1 1n tie penuMmata SAR-PDU 
ofaCPCS-PDU 



Fr 

reasseml 


ee 

Wy buffer 


i 


revji 


»;=0 
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IDLE 
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Procedure validate CPCS-POU 



Validate 
CPCS-POU 



Compute CRC32 



Langth = 0 Is reearuBd 
for user abort 




The value for the CPCS-CI 
J paiameter is taken from the 
"1 SAR-CI parameter of the last 
I SAR-UNfTDATA Signal 
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Appendix in 

Example CPCS-PDUs for the AAL type 5 

(This appendix does not forms an integral pan of this Recommendation) 

The values in the examples are in hexadecimal notation. 

a) Example 1 

40 octets filled with"0" 
CPCS-UU field=0 
CPIField=0 
Length=40 octets 
CRC-32=864d7f99 



00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 



00 00 00 00 00 00 00 00 
0000000000000000 
00 00 00 28 86 4d If 99 



b) Example 2 

40 octets filled with "1 
CPCS-UU field=0 
CPI Field=0 
Length=40 octets 
CRC-32^c55e457a 



ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


ff 


00 


00 


00 


28 


c5 


5e 


45 


7a 



c) Example 3 

40 octets counting: 1 to 40 
CPCS-UU field=0 
CPIField=0 
Length=40 octets 
CRC-32=bf671ed0 



01 02 03 04 05 06 07 08 
11. 12 13 14 15 16 17 18 
21 22 23 24 25 26 27 28 



09 Oa Ob Oc Od Oe Of 10 
19 la lb lc Id le If 20 
00 00 00 28 bf 67 le dO 
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1.361, B-ISDN ATM layer specification 

This recommendation describes: 

• the cell structure and ATM cell coding 
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• the User-Network Interface (UNI) 

• the Network-Node Interface (NNI). 

It defines the contents of the following fields of the headers for each format: 

• Generic flow control (GFC) field 

• Routing field (VPI/VCI) 

• Payload type (PT) field 

• Cell loss priority (CLP) field 

• Header error control (HEC) field 

The procedures are described in terms of service primitives exchanged with 
the upper and lower layers, i.e., an abstract manner for the logical exchange 
of information and control through a service access point. 
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1.362, B-ISDN ATM Adaptation Layer (AAL) functional 
description^ 

This recommendation describes the ATM Adaptation Layer (AAL), and its 
sublayers, the segmentation and reassembly sublayer (SAR), and the 
convergence sublayer (CS). In order to minimize the number of AAL 
protocols, it establishes four classes of service, which differ in terms ot 
timing relation between source and destination, bit rate (constant or variable), 
and connection mode. The four classes of service are: 

• circuit emulation constant bit ratio 

• variable bit rate video and audio 

• connection-oriented data transfer 

• connectionless data transfer. 

This recommendation was deleted since the service classes defined are no 
longer appropriate and are in conflict with the current F-senes 
recommendations. 
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1.363, B-ISDN Am Adaptation Layer (AAL) specification 

This recommendation defines 5 types of AAL and describes the interactions 
between the AAL and the next higher layer, interactions between the AAL 
and the ATM layer, and the AAL peer-to-peer operations. The AAL types 
are: 

. Type 1 for transfer of Service Data Units (SDU) with a constant source 
bit rate and delivery with the same bit rate, transfer of timing, and 
indication of lost or errored information 
. Type 2 for transfer of SDUs with a variable source bit rate, transfer of 

timing information, and indication of lost or errored information 
• Type 3/4 for transfer of SDU from one AAL user to one or more AAL 
users 

. Type 5 for transfer of the AAL Service Data Units (AAL-SDU) from 
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one user to another AAL user through the ATM network. 

This recommendation was deleted when the new 1.363,1 , 1.353 J, and 1.363,5 
were approved. 
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1.363.1, B-ISDN ATM Adaptation Layer (AAL), types 1 and 2 
specification 

This recommendation describes the interactions between the AAL and the 
next higher layer, interactions between the AAL and the ATM layer, and 
AAL peer-to-peer operations. This recommendation is based on the 
classification and the AAL functional organization originally described in 
1.362. It covers AAL type 1 and leaves a place holder for AAL type 2. (AAL 
type 2 is now defined in a 1.363.2.) 

Different combinations of SAR (Segmentation and Reassembly) sublayer and 
CSs (Convergence Sublayers) provide different Service Access Points 
(S APs) to the layer above the AAL. 
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1.363.2, B-ISDN ATM Adaptation Layer (AAL), type 2 
specification 

This recommendation describes the interactions between the AAL and the 
next higher layer, interactions between the AAL and the ATM layer, and 
AAL peer-to-peer operations. This recommendation is based on the 
classification and the AAL functional organization originally described in 
1.362. It covers AAL type 2 which is intended for bandwidth-efficient 
transmission of low-rate, short, and variable length packets in delay sensitive 
applications. Each AAL2 connection can carry multiple AAL 2 type 
information, for example, voice, dialed digit information, packet data. 

It is envisioned that there will be multiple SSCS defined for the different 
applications. 
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Recommendation 1.363.1 

B-ISDN ATM ADAPTATION LAYER SPECIFICATION: TYPE 1 AAL 

(Geneva, 1996) 

1 Introduction 

The ATM Adaptation Layer (AAL) enhances the service provided by the ATM layer to support 
functions required by the next higher layer. The AAL performs functions required by the user, 
control and management planes and supports the mapping between the ATM layer and the next 
higher layer. The functions performed in the AAL depend upon the higher layer requirements. 

The AAL supports multiple protocols to fit the needs of the different AAL service users. The service 
provided by the AAL type 1 to the higher layer and the functions performed are specified in this 
Recommendation. 

Abbreviations used in this Recommendation are listed in Annex A. Details of the data unit naming 
convention used in this Recommendation can be found in Annex B. 

1.1 Scope of the Recommendation 

This Recommendation describes the interactions between the AAL type 1 and the next higher layer, 
and the AAL type 1 and the ATM layer, as well as AAL type 1 peer-to-peer operations. 
Different combinations of SAR (Segmentation and Reassembly) sublayer and CSs (Convergence 
Sublayers) provide different Service Access Points (SAPs) to the layer above the AAL. 

2 AAL type 1 

2.1 Services provided by AAL type 1 
2.1*1 Definitions 

The layer services provided by AAL type.l to the AAL user are: 

transfer of service data units with a constant source bit rate and the delivery of them with the 
same bit rate; 

• transfer of timing information between source and destination; 

• transfer of structure information between source and destination; 

indication, if needed, of lost or errored information which is not recovered by AAL type 1. 

2.1.2 Primitives between AAL type 1 and the AAL user 
2.1.2.1 General 

At the AAL-SAP, the following primitives will be used between the AAL type 1 and the AAL user: 

• From an AAL user to the AAL, 

AAL-UNITDATA Request; 

• From the AAL to an AAL user, 

AAL-UNITDATA Indication. 
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An AAL-UNITDATA request primitive at the local AAL-SAP results in an AAL-UNITDATA 
indication primitive at its peer AAL-SAP. 

2.1.2.2 Definition of primitives 

2.1.2.2.1 AAL-UNITDATA request 

AAL-UNITDATA request (DATA [mandatory], 

STRUCTURE [optional]) 

The AAL-UNITDATA request primitive requests the transfer of the AAL-SDU, i.e. contents of the 
DATA parameter, from the local AAL entity to its peer entity. The length of the AAL-SDU is 
constant and the time interval between two consecutive primitives is constant. These two constants 
are a function of the AAL service provided to the AAL user. 

2.1.2.2.2 AAL-UNITDATA indication 

AAL-UNITDATA indication (DATA [mandatory], 

STRUCTURE [optional], 
STATUS [optional]) 

An AAL user is notified by the AAL that the AAL-SDU, i.e. contents of the DATA parameter, from 
its peer are available. The length of the AAL-SDU should be constant and the time interval between 
two consecutive primitives should be constant. These two constants are a function of the AAL 
service provided to the AAL user. 

2.1.2.3 Definition of parameters 

2.1.2.3.1 DATA parameter 

The DATA parameter carries the AAL-SDU to be sent or delivered. Its size depends on the specific 
AAL layer service used, and is described in 2.5.1.1 a) to 2.5.1.4 a). 

2.1.2.3.2 STRUCTURE parameter (optional use) 

The STRUCTURE parameter can be used when the user data stream to be transferred to the peer 
AAL entity is organized into groups of bits. The length of the structured block is fixed for each 
instance of the AAL service. The length is an integer multiple of 8 bits. An example of the use of this 
parameter is to support circuit mode bearer services of the 64 kbit/s-based ISDN. The two values of 
the STRUCTURE parameter are: 

START, and 

CONTINUATION. 

The value START is used when the DATA is the first part of a structured block which can be 
composed of consecutive DATA. In other cases, the structure parameter is set to CONTINUATION. 
The use of the STRUCTURE parameter depends on the type of AAL service provided. The use of 
this parameter is agreed prior to or at the connection establishment between the AAL user and the 
AAL. 
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2.1.2.3.3 STATUS parameter (optional use) 

The STATUS parameter identifies that the DATA is judged to be non-errored or errored. The 
STATUS parameter has two values: 

VALID, and 

INVALID. 

The INVALID status could also imply that the DATA is a dummy value. The use of the STATUS 
parameter and the choice of dummy value depend on the type of AAL service provided. The use of 
this parameter is agreed prior to or at the connection establishment between the AAL user and the 
AAL. 

2.1.3 Information flow across the ATM-AAL boundary 

Recommendation 1.361 describes the primitives exchanged between the ATM layer and the AAL. 
This subclause describes the usage of these primitives for AAL type 1. 

The AAL receives from the ATM layer the information in the form of a 48-octet ATM Service Data 
Unit (ATM-SDU). The AAL passes to the ATM layer information in the form of a 48-octet 
ATM-SDU. 

The submitted CLP (Cell Loss Priority) in the request primitive is set to the high priority by the AAL 
transmitter. The value of the receive loss priority in the indication primitive is ignored by the AAL 
receiver. 

The AUU (ATM-User-to-ATM-User) parameter is set to "0" in the request primitive. Future 
procedures may require that the AUU parameter can be set to "0" or "1". Such usage is reserved for 
future standardization. 

The congestion indication is ignored by the AAL receiver. 

The encoding principles for mapping information between the ATM layer and AAL type 1 are given 
in Annex C. 

2.1.4 Primitives between the SAR sublayer and the CS 

2.1.4.1 General 

These primitives model the exchange of information between the SAR sublayer and the Convergence 
Sublayer (CS). As there exists no Service Access Point (SAP) between the sublayers of the AAL type 
1 the primitives are called "invoke" and "signal" instead of the conventional "request" and 
"indication" to highlight the absence of the SAP. Functional model and SDL of AAL type 1 is given 
in Appendix I. 

2.1.4.2 SAR-UNITDATA invoke 

SAR-UNITDATA invoke at the AAL type 1 transmitter has the following parameters: 

Interface data: This parameter specifies the interface data unit passed from the CS to the 
SAR entity. The interface data is 47 octets, and represents a SAR-PDU payload. 
CSI: The Convergence Sublayer Indication (CSI), either "0" or " 1 ", is passed from the CS to 
the SAR entity. 

Sequence count: The sequence count value is passed from the CS to the SAR entity. The 
value of sequence count starts with 0, is incremented sequentially and is numbered 
modulo 8. 
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2.1.4.3 SAR-UNITDATA signal 

SAR-UNITDATA signal at the AAL type 1 receiver has the following parameters: 

• Interface data: This parameter specifies the interface data unit passed from the SAR to the 
CS entity. The interface data is 47 octets, and represents a SAR-PDU payload. 

• CSI: The CSI is passed from the SAR to CS entity, regardless of the check status (valid or 
invalid). 

• Sequence count: The sequence count value is passed from the SAR to CS entity, regardless 
of the check status (valid or invalid). 

• Check status: This parameter specifies the status of the sequence count and CSI, and has the 
value of either valid or invalid. 

2.2 Interaction with the management and control planes 

2.2.1 Management plane 

The following indications may be passed from the user plane to the management plane: 

• errors in the transmission of user information; 

• lost or misinserted cells (further study is required on whether it is necessary to distinguish 
between lost and misinserted cells for management purposes); 

• cells with errored AAL Protocol Control Information (AAL-PCI) (further study is required to 
determine if this indication is necessary for layer services supported by this AAL type); 

• loss of timing and synchronization; 

• buffer underflow and overflow. 

2.2.2 Control plane 

For further study. 

2.3 Functions of AAL type 1 

The following functions may be performed in the AAL type 1 in order to enhance the ATM layer 
service: 

a) segmentation and reassembly of user information; 

b) blocking and deblocking of user information; 

c) handling of cell delay variation; 

d) handling of cell payload assembly delay; 

e) handling of lost or misinserted cells; 

f) source clock frequency recovery at the receiver; 

g) recovery of the source data structure at the receiver; 

h) monitoring of AAL-PCI for bit errors; 

i) handling of AAL-PCI bit errors; 

j) monitoring of user information field for bit errors and possible corrective action. 
Other functions are for further study. 

NOTE - For some AAL users, the end-to-end QOS may be monitored. This may be achieved by calculating a 
CRC for the CS-PDU payload, carried in one or more cells, and transmitting the CRC results in the CS-PDU 
or by the use of OAM cells. Further study is required. 
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2.4 Segmentation and Reassembly (SAR) sublayer 



2.4. 1 Functions of the SAR sublayer 

The SAR sublayer functions are performed on an ATM-SDU basis. 

a) Mapping between CS-PDU and SAR-PDU 

The SAR sublayer at the transmitting end accepts a 47-octet block of interface data from the 
Convergence Sublayer (CS), and then prepends a one-octet SAR-PDU header to each block 
to form the SAR-PDU. 

The SAR sublayer at the receiving end receives the 48-octet block of data from the ATM 
layer, and then separates the SAR-PDU header. The 47-octet block of SAR-PDU payload 
(interface data) is passed to the CS. 

b) Existence of CS function 

The SAR sublayer has the capability to indicate the existence of a CS function. Associated 
with each 47-octet SAR-PDU payload, it receives this indication (CSI) from the CS and 
conveys it to the peer CS entity. 

c) Sequence numbering 

Associated with each SAR-PDU payload, the SAR sublayer receives a sequence count value 
from the CS. At the receiving end, it passes the sequence count value to the CS. The CS may 
use these sequence count values to detect lost or misinserted SAR-PDU payloads 
(corresponding to lost or misinserted ATM cells). 

d) Error protection 

The SAR sublayer protects the sequence count value and the CS indication against bit errors. 
It informs the receiving CS by the value of check status whether the sequence count value 
and/or the CS indication are errored. 

2.4.2 SAR protocol 

The SAR-PDU header together with the 47 octets of the SAR-PDU payload comprises the 48-octet 
ATM-SDU (cell information field). The size and positions of the fields in the SAR-PDU are given in 
Figure 1. 



Cell header 


SN field 


SNP field 


SAR-PDU payload 




4 bits 


4 bits 


47 octets 



SAR-PDU header 
K — X 

SAR-PDU (48 octets) 
K — * 

T1 81 1320-90 



Figure 1/1.363.1 - SAR-PDU format of AAL type 1 



2.4.2.1 Sequence Number (SN) field 

The SN field is divided into two subfields as shown in Figure 2. The sequence count field carries the 
sequence count value provided by the Convergence Sublayer (CS). The CSI bit carries the CS 
indication provided by the CS. The default value of the CSI bit is "0". 

The least significant bit of the sequence count value is right justified in the sequence count field. 
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CSIbit 


Sequence count field (3 bits) 


< 


SN field (4 bits) 


> 



T1 81 7600-92 



Figure 2/1.363.1 - Sequence Number (SN) field format 
2.4.2.2 Sequence Number Protection (SNP) field 

The SNP field provides error detection and correction capabilities over the SAR-PDU header. The 
format of this field is given in Figure 3. A two-step approach is used for the protection: 

1) The Sequence Number (SN) field is protected by a 3-bit CRC code. 

2) The resulting 7-bit codeword is protected by an even parity bit; i.e. the parity bit is set such 
that the 8-bit SAR-PDU header has an even parity. 



CRC field (3 bits) 


Even parity 
bit 


< 


SNP field (4 bits) 


> 



T1817610-92 



Figure 3/1.363.1 - SNP field format 

The receiver is capable of either single-bit error correction or multiple-bit error detection. 

a) Operations at transmitting end 

The transmitter computes the CRC value across the first 4 bits of the SAR-PDU header and 
inserts the result in the CRC field. 

The notation used to describe the CRC is based on the property of cyclic codes. The 
elements of an n -element codeword are thus the coefficients of a polynomial of order n - 1. 
In this application, these coefficients can have the value 0 or 1 and the polynomial operations 
are performed using modulo 2 operations. For example, a code vector such as 1011 can be 
represented by the polynomial P(jc)= jc 3 + x + 1. The polynomial representing the content of 
the SN field is generated using the first bit of the SN field as the coefficient of the highest 
order term. 

The CRC field consists of three bits. It shall contain the remainder of the division 
(modulo 2) by the generator polynomial jc 3 + x + 1 of the product x 3 multiplied by the content 
of the SN field. The coefficient of the x 2 term in the remainder polynomial is left justified in 
the CRC field. 

After completing the above operations, the transmitter inserts the even parity bit. 

b) Operations at receiving end 

The receiver has two different modes of operation: correction mode and detection mode. 
These modes are related as shown in Figure 4. The default mode is the correction mode, 
which provides for single-bit error correction. At initialization, the receiver is set up in this 
default mode. 
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(valid SN after correction) 
Multi-bit error detected 
(invalid SN) 

SN Sequence number 

Figure 4/1.363.1 - SNP: receiver modes of operation 

The receiver examines each SAR-PDU header by checking the CRC bits and even parity bit. If a 
header error is detected, the action taken depends on the state of the receiver. In the "Correction 
Mode", only single-bit errors can be corrected and the receiver switches to "Detection Mode". In 
"Detection Mode", all SAR-PDU headers with detected errors are declared to have an invalid SN; 
however, when a SAR-PDU header is examined and found not to be in error, the receiver switches to 
"Correction Mode". 

Tables 1 and 2 give the detailed operations of the receiver in the "Correction Mode" and "Detection 
Mode", respectively. The operation is based on the combined validity of the CRC and parity check 
bit. 

The receiver conveys the sequence number count and the CS indication to the CS together with SN 
check status (valid or invalid). 



Table 1/1.363.1 - Operations in Correction Mode 



CRC syndrome 


Parity 


Action on current 
SN + SNP 


Reaction for next 
SN + SNP 


Zero 


No violation 


No corrective action. 
Declare SN valid. 


Continue in Correction 
Mode 


Non-zero 


Violation 


Single-bit correction 
based on syndrome. 
Declare SN valid. 


Switch to Detection 
Mode 


Zero 


Violation 


Correct parity bit. 
Declare SN valid. 


Switch to Detection 
mode 


Non-zero 


No violation 


No corrective action: 
multi-bit errors are 
uncorrectable. Declare 
SN invalid. 


Switch to Detection 
mode 
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Table 2/1.363.1 - Operations in Detection Mode 



CRC syndrome 


Parity 


Action on current 
SN + SNP 


Reaction for next 
SN + SNP 


Zero 


No violation 


No corrective action. 
Declare SN valid. 


Switch to Correction 
Mode 


Non-zero 


Violation 


No corrective action. 
Declare SN invalid. 


Continue in Detection 
Mode 


Zero 


Violation 


No corrective action. 
Declare SN invalid. 


Continue in Detection 
mode 


Non-zero 


No violation 


No corrective action. 
Declare SN invalid. 


Continue in Detection 
mode 



2.5 Convergence Sublayer (CS) 

2.5.1 Functions of the CS 

The CS may include the following functions: 

a) Blocking of user information to form a 47-octet block of SAR-PDU payload is performed at 
this sublayer. If no octet interleaving is applied, the AAL-SDUs are sequentially 
concatenated. They are placed left justified in the 47-octet block beginning from the first 
octet available for user information. The deblocking function is the reverse of the blocking 
function. It segments the user information into a stream of AAL-SDUs again. 

b) Handling of cell delay variation is performed at this sublayer for delivery of AAL-SDUs to 
an AAL user at a constant bit rate. 

c) Handling of SAR-PDU payload assembly delay may be performed by partially filling the 
SAR-PDU payload. 

d) Processing of sequence count may be performed at this sublayer. The sequence count value 
and its error check status provided by the SAR sublayer can be used by the CS to detect cell 
loss and misinsertion. Further handling of lots and misinserted cells is also performed in this 
sublayer. 

e) The CS can utilize the CS indication provided by the SAR sublayer to support CS functions 
for some AAL users. When the CS indication is not used, the CSI bit is set to "0" by the 
transmitter, and no further CS action related to that indication is performed at the receiver, 
i.e. the CS receiver ignores the received CSI value. 

f) For AAL users requiring recovery of source clock frequency at the destination end, the AAL 
can provide a mechanism for a timing information transfer. 

g) For some AAL users, this sublayer provides the transfer of structure information between 
source and destination. 

h) For video and high quality audio signal transport, forward error correction may be performed 
to protect against bit errors. This may be combined with interleaving of AAL user bits (i.e. 
octet interleaving) to correct cell losses. 

i) The CS may generate reports giving the status of end-to-end performance as deduced by the 
AAL. The performance measures in these reports could be based on: 

• events of lost and misinserted cells; 

• buffer underflow and overflow; 

• bit error events. 
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AAL type 1 protocol aims at having as many common procedures as possible among various types of 
CBR services in an ATM network. As such, AAL type 1 CS protocol is somewhat of a tool kit, 
whereby a specific higher layer needs to choose procedures given in this Recommendation, taking 
account of required service features (i.e. synchronous or asynchronous transport), required 
performance (i.e. error and delay characteristics at the AAL service boundary), and anticipated 
network performance (i.e. cell losses and delay variations). 

The following subclauses describe CS functions needed for four layer services, i.e. circuit transport, 
video signal transport, voiceband signal transport and high quality audio signal transport. These 
subclauses also refer to a specific procedure which is defined in 2.5.2, where the description of each 
procedure is independent from CS functions. These four layer services and associated description of 
required procedures are general and not exhaustive. Appendix H gives informative and example 
parameters, i.e. a set of procedures and options, for some specific AAL type 1 services. Having this 
structural description, this Recommendation gives the ground for a generic protocol to support a 
large number of CBR services. 

2.5.1.1 Functions of the CS for circuit transport 

The following functions support both asynchronous and synchronous circuit transport. Asynchronous 
circuit transport will provide transport of signals from constant bit rate sources whose clocks are not 
frequency-locked to a network clock. Examples are Recommendation G.702 signals at 1.544, 2.048, 
6.312, 8.448, 32.064, 44.736 and 34.368 Mbit/s. Synchronous circuit transport will provide transport 
of signals from constant bit rate sources whose clocks are frequency-locked to a network clock. 
Examples are signals at 64, 384, 1536 and 1920 kbit/s as described in Recommendation 1.231. 
NOTE - Another possible example of synchronous circuit transport is conveyance of SDH signals described 
in Recommendation G.709. 

a) Handling of AAL user information 

The length of the AAL-SDU is one bit, when asynchronous circuit transport utilizes the 
Synchronous Residual Time Stamp (SRTS) method described in 2.5.2.2.2. 
For those AAL users who require transfer of structured data, i.e. 8 kHz structured data for 
circuit mode bearer services of the 64 kbit/s-based ISDN, the STRUCTURE parameter 
option of the primitives defined in 2.1.2 will be used. The CS uses the Structured Data 
Transfer (SDT) method described in 2.5.2.3. 

b) Handling of cell delay variation 

A buffer is used to support this function. The size of this buffer is dependent upon 
specifications provided in Recommendation 1.356. 

In the event of buffer underflow, it may be necessary for the CS to maintain bit count 
integrity by inserting the appropriate number of dummy bits. In the event of buffer overflow, 
it may be necessary for the CS to maintain bit count integrity by dropping the appropriate 
number of bits. 

When Recommendation G.702 1.544-Mbit/s and 2.048-Mbit/s signals are being transported, 
the inserted dummy bits shall be all " 1 "s. 

c) Handling of lost and misinserted cells 

The sequence count values are further processed at this sublayer to detect lost and 
misinserted cells. Detected misinserted cells are discarded. The CS procedure to be used for 
sequence count processing is described in 2.5.2. 1 . 

In order to maintain the bit count integrity of the AAL user information, it may be necessary 
to compensate for lost cells detected by buffer underflow and sequence count processing by 
inserting the appropriate number of dummy SAR-PDU payloads. The content of this dummy 
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SAR-PDU payload depends on the AAL service being provided. For example, this dummy 
SAR-PDU payload is all 'T's for Recommendation G.702 1.544 Mbit/s and 2.048-Mbit/s 
. signals. 

d) Handling of timing relation 

This function is required for delivery of AAL-SDUs to an AAL user at a constant bit rate. 
Recovered source clock should have satisfactory jitter and wander performance. For 
example, the jitter and wander performance for Recommendation G.702 signals is specified 
in Recommendations G.823 and G.824, for which the CS procedure to be used (the SRTS 
method) is described in 2.5.2.2.2. 

2.5.1.2 Functions of the CS for video signal transport 

The following functions support transport of video signals for interactive and distributive services: 

a) Handling of AAL user information 

The length of the AAL-SDU is one octet, when utilizing the correction methods described 
in 2.5.2.4. 

For those AAL users who require transfer of structured data, the STRUCTURE parameter 
option of primitives defined in 2.1.2 will be used. The CS uses the SDT method described 
in 2.5.2.3. 

Depending on the type of AAL service provided (i.e. the interface to the AAL user), the 
STATUS parameter defined in 2.1.2 will be passed to the AAL user to facilitate further 
picture processing, i.e. error concealment or not. 

b) Handling of cell delay variation 

A buffer is used to support this function. The size of this buffer is dependent upon 
specifications provided in Recommendation 1.356. 

In the event of buffer underflow, it may be necessary for the CS to maintain bit count 
integrity by inserting the appropriate number of dummy bits. In the event of buffer overflow, 
it may be necessary for the CS to maintain bit count integrity by dropping the appropriate 
number of bits. 

c) Handling of lost and misinserted cells 

The sequence count values are further processed at this sublayer to detect lost and 
misinserted cells. Detected misinserted cells are discarded. The CS procedure to be used for 
sequence count processing is described in 2.5.2.1. 

In order to maintain the bit count integrity of the AAL user information, it may be necessary 
to compensate for lost cells detected by buffer underflow and sequence count processing by 
inserting the appropriate number of dummy SAR-PDU payloads. The content of this dummy 
SAR-PDU payload depends on the AAL service being provided. 

Information in lost cells may be recovered by the mechanism described in e). 

d) Handling of timing relation 

This function is required for delivery of AAL-SDUs to an AAL user at a constant bit rate. 

Some AAL users may require source clock frequency recovery, i.e. recovery at the receiving 
end of camera clock frequency which is not locked to the network clock. The CS procedures 
available for that purpose are given in 2.5.2.2. 

e) Correction of bit errors and lost cells 

This is an optional function provided for those AAL users requiring error correction, i.e. bit 
error and/or cell loss performance better than that provided by the ATM and physical layer. 



10 



Recommendation 1.363.1 (08/96) 



• 



Examples are unidirectional video services for contribution and distribution. This function 
may be performed with the CS procedure described in 2.5.2.4. 

2.5.1.3 Functions of the CS for voiceband signal transport 

The following functions support transport of a single voiceband signal, i.e. one 64 kbit/s A-law or 
jx-law coded Recommendation G.71 1 signal. 

a) Handling ofAAL user information 

The length of the AAL-SDU is one octet. Forty-seven consecutive AAL-SDUs constitute 
one SAR-PDU payload, i.e. partially filled cells are not used. The CS provides structured 
data transfer with single octet delineation, i.e. the pointer is not used. 

b) Handling of cell delay variation 

A buffer is used to support this function. The size of this buffer depends on specifications 
provided in Recommendation 1.356. 

c) Handling of lost and misinserted cells 

For voiceband signals, there is no need to detect misinserted cells. 

The receiving AAL entity must detect/compensate for lost cell events to maintain bit count 
integrity and must also minimize the delay, i.e. to alleviate echo performance problems, in 
conveying the individual voiceband signal octets from the SAR-PDU payload to the AAL 
user. The receiving AAL entity may take actions based on the received SN values, but such 
actions must not increase the conveyance delay across the AAL receiving entity beyond the 
nominal CDV value to alleviate echo performance problems. 

The AAL receiving entity must accommodate a sudden increase or decrease in the nominal 
cell transfer delay. (Such a change in cell transfer delay can be the result of a protection 
switching event in the network.) 

d) Handling of timing relation 

The CS provides synchronous circuit transport for the voiceband signal. 
NOTE 1 - Example receiver techniques using a timing-based mechanism or a buffer-fill-based 
mechanism, possibly supplemented by an SN processing algorithm that does not introduce 
additional delay, are given in Appendix IE. 

NOTE 2 - For transporting signals of speech and 3.1 kHz audio bearer services as specified in 
64 kbit/s ISDN, the need for A/^-law conversion is identified. The conversion between A-law and 
H-law coded PCM octets is as specified in Recommendation G.711. This conversion function is 
outside the scope of this Recommendation. 

2.5,1.4 Functions of the CS for high quality audio signal transport 

The capabilities of AAL type 1 are in principle applicable for transfer of high quality audio signals. 

a) Handling of AAL user information; 

b) Handling of cell delay variation; 

c) Handling of lost and misinserted cells; 

d) Handling of timing relation; 

e) Correction of bit errors and lost cells. 

2.5.2 Convergence Sublayer (CS) protocol 

The following subclauses describe CS procedures to be provided for implementing CS functions. 
The use of each procedure depends on the required CS functions and is given in 2.5.1. 
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2.5.2.1 Sequence count operations 



2.5.2.1.1 Sequence count operations at the transmitting end 

At the transmitting end, the CS provides the SAR with a sequence count value and a CS indication 
associated with each SAR-PDU payload. The count value starts with 0, is incremented sequentially 
and is numbered modulo 8. 

2.5.2.1.2 Sequence count operations at the receiving end 

At the receiving end, the CS receives from the SAR the following information associated with each 
SAR-PDU payload: 

• sequence count; 

• CS indication; 

• check status of the sequence count and CS indication. 

The use of sequence count values and CS indications will be specified on a service specific basis. 
See 2.4.2 for details about the check status processing. 

The CS processing at the receiving end may identify lost or misinserted SAR-PDU payloads. This 
will be useful for many CBR services. 

CS processing may identify the following conditions: 

• SAR-PDU payload sequence normal (i.e. in correct sequence); 
SAR-PDU payload loss; 

• SAR-PDU payload misinsertion. 

Processing of sequence count values may provide additional information to related entities within the 
CS, as required. Some examples are: 

• location of lost SAR-PDU payload in the incoming SAR-PDU stream; 

• number of consecutive SAR-PDU payloads lost; 

• identification of misinserted SAR-PDU payload. 

Informative examples of algorithms for the processing of sequence count values are given in 
Appendix HI. Independent of which type of algorithm is used, additional mechanisms have to be 
realized to preserve bit count integrity. This can, for example, be achieved by defining a time 
window (whose width is related to the nominal CDV) around the expected arrival instant of the next 
cell or by interpreting the buffer-fill level and inserting or discarding the appropriate number of bits. 

NOTE - Processing of sequence count values may be subject to performance specifications. The performance 
specifications will be applied on a service specific basis. 

2.5.2.2 Source clock frequency recovery method 

For synchronous CBR services, the clock is locked to a clock available from the network. 

The CS provides two methods for the support of asynchronous CBR services with clocks not locked 
to a network clock. 

• Adaptive clock method for those services which need to comply with jitter requirements but 
which do not need to comply with wander requirements, i.e. Recommendation G.823/G.824; 

• Synchronous Residual Time Stamp (SRTS) method for those services which need to comply 
with jitter and wander requirements, i.e. Recommendation G.823/G.824. 
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If a circuit transport equipment is connected to the public network, the requirements of jitter and 
wander depend on services. For services which need to meet the jitter and wander specifications in 
Recommendation G.823/G.824, the use of SRTS method is recommended. In private networks with 
no stringent wander requirement, the adaptive clock method may be used. 

2.5.2.2.1 Adaptive clock method 

The adaptive clock method is a general method for source clock frequency recovery. No explicit 
timing information of the source clock is transported by the network; the method is based on the fact 
that the amount of transmitted data is an indication of the source frequency, and this information can 
be used at the receiver to recover the source clock frequency. By averaging the amount of received 
data over a period of time, CDV (Cell Delay Variation) effects are counteracted. The period of time 
used for averaging depends on the CDV characteristics. 

The adaptive clock method is implemented at the receiving AAL. The implementation of the method 
is not standardized. One possible method to measure the amount of data is to use the fill level of the 
AAL user data buffer. The following is the general description of this method and does not preclude 
other adaptive clock methods. 

The receiver writes the received data into a buffer and then reads it out using a locally generated 
clock. Therefore, the fill level of the buffer depends on the source frequency and it is used to control 
the frequency of the local clock. Operations are the following: the fill level of the buffer is 
continuously measured and the measure is used to drive the phase-locked loop generating the local 
clock. The method maintains the fill level of the buffer around its medium position. To avoid buffer 
underflow or overflow, the fill level is maintained between two limits. When the level in the buffer 
goes to the lower limit, this means the frequency of the local clock is too high compared to the one of 
the source and so it has to be decreased; when the level in the buffer goes to the upper limit, the 
frequency of the local clock is too low compared to the one of the source and so it has to be 
increased. 

2.5.2.2.2 Synchronous Residual Time Stamp (SRTS) method 

a) General 

The Synchronous Residual Time Stamp (SRTS) method uses the Residual Time Stamp 
(RTS) to measure and convey information about the frequency difference between a 
common reference clock derived from the network and a service clock. The same derived 
network clock is assumed to be available at both the transmitter and the receiver. If the 
common network reference clock is unavailable (i.e. when working between different 
networks which are not synchronized), then the asynchronous clock recovery method will be 
in a mode of operation associated with "Plesiochronous network operation" which is 
described in item e). The SRTS method is capable of meeting the jitter specifications of the 
2.048 Mbit/s hierarchy in Recommendation G.823 and the 1.544 Mbit/s hierarchy in 
Recommendation G.824. 

The following is a description of the SRTS method. The description uses the notation below: 

/, - service clock frequency; 

/„ - network clock frequency, i.e. 155.52 MHz; 

- derived reference clock frequency, /„ = fJx where x is a rational 
number to be defined later; 
N - period of RTS in cycles of the service clock of frequency/,; 

T - period of the RTS in seconds; 
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M{M nQ m, Mmax, Mmin)- number of /„ cycles within a (nominal, maximum, minimum) RTS 
period; 

M q - largest integer smaller than or equal to M. 

The SRTS concept is illustrated in Figure 5. In a fixed duration T measured by /V service 
clock cycles, the number of derived network clock cycles M q is obtained at the transmitter. If 
M q is transmitted to the receiver, the service clock of the source can be reconstructed by the 
receiver, since it has the necessary information: /„, M q and N. However, M q is actually made 
up of a nominal part and a residual part. The nominal part M nom corresponds to the nominal 
number of f M cycles in T seconds and is fixed for the service. The residual part conveys the 
frequency difference information as well as the effect of the quantization and thus can vary. 
Since the nominal part is a constant, it can be assumed that the nominal part of M q is 
available at the receiver. Only the residual part of M q is transmitted to the receiver. 
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Figure 5/1,363.1 - The concept of Synchronous Residual Time Stamp (SRTS) 



A simple way of representing the residual part of M q is by means of the RTS, whose 
generation is shown in Figure 6. Counter Q is a P-bit counter which is continuously clocked 
by the derived network clock. The output of counter Q is sampled every N service clock 
cycle. This P-bit sample is the Residual Time Stamp. 
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Figure 6/1.363.1 - Generation of Residual Time Stamp (RTS) 

With a knowledge of the RTS and the nominal part of M q at the receiver, M q is completely 
specified. M q is used to produce a reference timing signal for a Phase-Locked Loop to obtain 
the service clock. 
Choice of parameter 

The minimum size of the RTS required to unambiguously represent the residual part of M q is 
a function of iV, the ratio fjf„ and the service clock tolerance, ± e. Let y be the difference 
between M nom and the maximum or minimum value of M (denoted as Mmax, Mmin)- The 
difference y is given by: 

Js 

In order that M q can be unambiguously identified, the following conditions must be satisfied 
(see Figure 5); 

where denotes the smallest integer larger than or equal toy. 

The following parameter values are used for the asynchronous circuit transport of 
Recommendation G.702 signals: 

N = 3008 (total number of bits in eight S AR-PDU payloads); 
1 <fJf, < 2; 

Tolerance = 200 x lO^ 6 ; 
Size of RTS =4 bits. 

The introduction of any AAL convergence sublayer overhead into the SAR-PDU payload 
will reduce the amount of payload available for the transport of AAL user data. This will 
reduce the number of service clock cycles over which the RTS period is specified, since the 
RTS period is defined over a fixed number of SAR-PDU payloads. The RTS period 
parameter, N, can be adjusted to accommodate such cases. 

The CS overhead has to be allocated so that the RTS period always remains a constant 
number of service clock cycles. Therefore, the CS overhead must reduce the user data 
transport capacity by a constant amount over the fixed number of SAR-PDU payloads for 
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which the RTS period is defined. As an example, the P format in the SDT method is used 
exactly once per cycle, where a cycle is the sequence of eight consecutive SAR-PDUs with 
the sequence count values 0 through 7, /V is reduced from 3008 to 3000. 

c) Derived reference clocks 

For SDH and non-SDH physical layers, a clock at frequency f% = 8 kHz, synchronized to a 
common network clock, is available from which clocks at frequencies 

19 440 

fnx = h x— ^kHz* * =0, 1, 2 ... 11 

can be derived. This set of derived frequencies can accommodate all service rates from 
64 kbit/s up to the full capacity of the STM-1 payload. The exact value of f„ to be used is 
uniquely specified since the frequency ratio is constrained by 1 <fjf < 2. 

As an example, to support a service rate of 1544 kbit/s or 2048 kbit/s, the derived network 
frequency will bef„ =f% x 19 440/2 6 = 2430 kHz. As a further example, the derived network 
frequency for a service rate of 34 368 kbit/s and 44 736 kbit/s will be 38 880 kHz and 
77 760 kHz respectively. 

NOTE - This standard does not imply that an actual implementation explicitly derives a clock at 
frequency /g and then, in turn, derives another clock at frequency /„ by performing the multiplication 
by 19 440 and division by 2 k entailed in the stated formula for/„. 

Administrations/ROAs may use existing network clocks to support national service in a 
non-SDH ATM network. 

d) Transport of the RTS 

The 4-bit RTS is transmitted in the serial bit stream provided by the CSI bit in successive 
SAR-PDU headers. The modulo 8 sequence count provides a frame structure over 8 bits in 
this serial bit stream. Four bits of the framed 8 bits are allocated for the RTS and the 
remaining 4 bits are available for other uses. The SAR-PDU headers with the odd sequence 
count values of 1, 3 5 and 7 are used for RTS transport. The MSB of the RTS is placed in the 
CSI bit of the SAR-PDU header with the sequence count of 1. 

e) Plesiochronous network operation 

The issue about the accommodation of plesiochronous operation (i.e. when a common 
reference clock is not available from the network) needs to be addressed. This scenario must 
be accommodated in such a way that the recovered clock satisfies the requirements specified 
in Recommendations G.823 and G.824 for Recommendation G.702 signals. However, the 
detailed method of dealing with plesiochronous operation is not standardized. 

2.5.2.3 Structured Data Transfer (SDT) method 

The CS procedure for structured data transfer supports any fixed octet-based structure. In particular, 
it supports 8 kHz-based structures used in circuit-mode services of Recommendation 1.231. When 
the structure size is greater than one octet, the CS procedure uses a pointer to delineate the structure 
boundaries. 

The STRUCTURE parameter in the AAL-UNTTDATA request and AAL-UNTTDATA indication 
primitives is used to convey structure information between the AAL and the AAL user. See 2.1.2 for 
definition of primitives and parameters. 

The 47-octet SAR-PDU payload used by the CS has two formats, called non-P and P format as 
shown in Figure 7. 
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CSI bit = 0 if SRTS method is not being used. 

= RTS bit value if SRTS method is being used [see 2.5.2.2.2 d )]. 
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b) P format 



Figure 7/1.363.1 - Format of SAR-PDU payload for structured data transfer method 



With SDT, the blocking of AAL user information into SAR-PDU payloads at the sending AAL-CS 
and the deblocking of AAL user information from a SAR-PDU payload at the receiving AAL-CS is 
required to: 

maintain the integrity of each AAL user octet transferred between the AAL-CS and the AAL 
user by aligning each AAL user octet with a payload octet position; 

maintain the sequential order of the AAL user octets with the first AAL user octet in a 
payload assigned to the payload octet position adjacent to the SAR-PDU header (i.e. non-P 
format payload) or SDT header (i.e. P format payload). 
When the block size value is "1", the SDT protocol generates only non-P format SAR-PDU 
payloads, since the preservation of octet integrity provides the necessary structure boundary 
information. For block sizes greater than "l", the SDT protocol requires the generation of a pointer 
(i.e. P format payload) to provide SDT block boundary information once in each eight SAR-PDUs 
payloads associated with a sequence count cycle. 

a) Operations of the non-P format 

In the non-P format, the entire CS-PDU is filled with user information. This format is always 
used if the sequence count value in the SAR-PDU header is 1, 3, 5 or 7. 

b) Operations of the P format 

The CS procedure only uses the P format when the block size is greater than one octet. 

In the P format, the first octet of the SAR-PDU payload is the pointer field. The remainder is 

filled with user information. This format may be used only if the sequence count value in the 

SAR-PDU header is 0, 2, 4 or 6. 

The format of the pointer field is shown in Figure 8. 
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Figure 8/1.363.1 - Pointer field format 



The pointer field contains the binary value of the offset, measured in octets, between the end of the 
pointer field and the first start of the structured block in the 93-octet payload consisting of the 
remaining 46 octets of this SAR-PDU payload and the 47 octets of the next SAR-PDU payload. This 
offset ranges between 0 and 93 inclusive. The offset value 93 is used to indicate that the end of the 
93-octet payload coincides with the end of a structured block. Moreover, the dummy offset value 127 
is used when no structure boundary is being indicated. 

The binary value of the offset is inserted right justified in the offset field, i.e. the least significant bit 
of the offset is transmitted last. The first bit of the pointer field is used to provide an even parity over 
the pointer field. 

The P format is used exactly once in every cycle, where a cycle is the sequence of eight consecutive 
SAR-PDUs with sequence count values 0 through 7. The P format is used at the first available 
opportunity in a cycle to point to a start of a structure boundary. If neither a start of a structure 
boundary nor an end of a structure boundary is present in a cycle, then the P format with the dummy 
offset value in the pointer field is used at the last opportunity in the cycle, i.e. SAR-PDU with 
sequence count value 6. 

If a start of a structure boundary is not present in a cycle but coincides with the beginning of the next 
cycle, then the P format with offset value 93 in the pointer field is used in the SAR-PDU with 
sequence count value 6 and the P format with offset value 0 in the pointer field is used in the SAR 
SAR-PDU with sequence count value 0 in the next cycle. 

In keeping with the above pointer rule, the first structured block to be transmitted after the AAL 
connection is established uses the P format with sequence count value in the SAR-PDU header equal 
to 0 and with the first octet of the structured data placed in the second octet of the SAR-PDU 
payload. 

2.5.2.4 Correction methods for bit errors and/or cell losses 

Three correction methods are described: 

• Correction method for bit errors; 

• Correction method for bit errors and cell losses without delay restrictions; 

• Correction method for bit errors and cell losses with delay restrictions. 

2.5.2.4.1 Correction method for bit errors 

This correction method makes use of Forward Error Correction (FEC) using the Reed-Solomon 
(128, 124) codes which are able to correct up to 2 errored octets. Reed-Solomon codes to be used are 
built over Galois Field (256) and the generator polynomial is given by: 

ri(x-a' + *) 

1=0 
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where a is a root of the binary primitive polynomial / + * 7 + * 2 + x + 1. and kis the base exponent 
of the generator polynomial with = 120. 

In the transmitting CS, the 4-octet Reed-Solomon code is ° f inC ° ming 

from the upper layer. See Figure 9 for the structure and format of the FEC block. 
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Figure 9/1.363.1 - Structure and format of a FEC block 

A FEC block is organized as a group of 47 consecutive FEC frames. Each FEC frame contains 
l^^ fSFEC block £ 128 x 47 - 6016 octet, Such a FEC block constates one 
CS-PDU. 

For the synchronization of the CS-PDU, the CS indicator ^ 
the first S AR-PDU payload and is set to 0 for the remaining S AR-PDUs of he CS-PDU. This 
the CS indication bit precludes the use of the SDT method as specified in 2.5.2.3. 
This method can mainly perform the following correction: 

2 errored octets in each FEC frame if there is no cell loss. 
This method is applicable when only cell loss detection is needed and there is no cell correction. Cell 
Lss d™Sn impts the insertio/of 47 consecutive dummy octet, Misinserted cells which have 
been detected are merely discarded in the CS. 

The overhead of this method is 3.1% and the delay is approximately 3 cells at the receiver. 
2 5 2 4 2 Correction method for bit errors and cell losses without delay restrictions 

Galois Field (256) and the generator polynomial is given by: 

ri(%-°'") 

where a is a root of the binary primitive polynomial / + * 7 + * 2 + x + 1. and * is the base exponent 
of the generator polynomial with k = 120. 
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In the transmitting CS, the 4-octet Reed-Solomon code is appended to 124 octets of incoming data 
from the upper layer. The resulting 128-octet-long blocks are then forwarded to the octet interleaver. 
See Figure 10 for the format of the interleave matrix. 
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Figure 10/1.363.1 - Structure and format of the long interleaver matrix 



The octet interleaver is organized as a matrix of 128 columns and 47 rows. The interleaver is used as 
follows: at the input, incoming 128-octet-long blocks are stored row by row (one block 
corresponding to one row); at the output, octets are read out column by column. The matrix has 
128 x 47 = 6016 octets, corresponding to 128 SAR-PDU payloads. These 128 SAR-PDU payloads 
constitute one CS-PDU. 

In this process, the loss of one SAR-PDU payload in the matrix implies one erasure to correct in each 
row of the matrix. Erasures correspond to dummy cell payloads inserted in the cell flow when a cell 
loss has been detected. Misinserted cells which have been detected are merely discarded in the CS. 

For the synchronization of the CS-PDU, the CS indicator bit of the SAR-PDU header is set to 1 for 
the first SAR-PDU payload of the CS-PDU. This use of the CS indication bit precludes the use of the 
SDT method as specified in 2.5.2.3. 

Within any CS-PDU matrix, this method can perform the following corrections: 

• 4 cell losses; or 

• 2 cell losses and 1 errored octet in each row; or 

• 2 errored octets in each row if there is no cell loss. 

The overhead of this method is 3.1% and the delay is 128 cells both at the sending side and the 
receiving side. 

2.5.2.4.3 Correction method for bit errors and cell losses with delay restrictions 

a) Characteristics of the method 

The method combines FEC using Reed-Solomon codes and octet interleaving of data. The 
size of the interleaver is 16 cells, the interleaving matrix has 8 rows and 94 columns. The 
method utilizes Reed-Solomon (94, 88) codes. The erasure mode is used for the correction of 
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dummy octets corresponding to cell loss locations. Reed-Solomon codes to be used are built 
over Galois Field (256) and the generator polynomial is given by: 

n(x-a i+ *) 

where a is a root of the binary primitive polynomial + x 1 + x 2 + x + 1, and k is the base 
exponent of the generator polynomial with k = 120. 

A diagonal interleaving mechanism is used to decrease the processing delay of the method. 
In the interleaver, the writing mode and the reading mode are alternate. The process in the 
interleaver is continuous, i.e. only one interleaver is necessary at each end. See Figure 11 for 
structure of the short interleaver matrix. 
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Figure 11/1.363.1 - Structure of the short interleaver matrix 



Operation at the transmitting end 

RS codes for a row are calculated prior to writing in the interleaver. The writing order in the 
interleaver is horizontal. The reading order is diagonal. The process is operated octet by 
octet. Let a (i, j) be a coefficient (i.e. an octet) in the matrix, where i is the row number and; 
the column number. Then the sequence of coefficients to be read out of the matrix diagonally 
is as follows: 

a (i + i, ; - 1), a a (i - j + 7) , ... 
The format and organization of the interleaver is given in Figure 12. 
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Figure 12/1.363.1 - Format and organization of the short interleaver matrix 
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For a correct reading order of the diagonal mechanism, a virtual column is added 
(Number 95). It is used only for counting; it does not contain any information and it is not 
transmitted. It is mentioned in "parentheses" in the following sequences only to permit a 
good understanding of the reading order. Examples of 47 octets sequences that are read out 
of the interleaver are given hereafter: 

seq. k : (B95),A1,H2,G3,. M A9,H10,..,A17,..,A25,..,A33,..,A41 ( ..,C47. 
seq. k+1 : B48,A49fl50,..,B56,..,B64,..372,..,B80,..388,..,D94. 
seq. k+2 : (C95)31,A2,H3,G4,. M B9 ) ..317,. M B25,..,B33,..,B41,..,D47. 
seq. k+3 : C48 T B49,A50,..,C56 V .,C64,..,C72,..,C80,..,C88,..,E94. 
seq. k+4 : (D95),C1,B2 V .,C9,..,C17,..,C25,..,C33,. M C41,. M E47. 



1) Operation at the beginning of the communication 

At the beginning of the communication, the reading of the interleaver begins, before it is 
completely filled up. The reading process begins as soon as the first octet has been 
written in the interleaver. As a result, in the first SAR-PDUs of the communication, only 
some octets carry valid information. Other octets contain dummy information as they 
correspond to positions in the interleaver which have not yet been filled. The 
communication begins as follows (x: dummy octets): 

1st SAR-PDU : Al,x..x,A9,x..x,A17,x..x,A25,x..x,A33,x..x,A41,x..x. 
2nd SAR-PDU : x,A49,x..x,A57,x..x,A65,x..x,A73,x..x,A81,x..x,A89,x..x. 
3rd SAR-PDU : Bl,A2,x..x,B9,A10,x..x,B17,A18,x..x,B25,A26,x..x,B33,A34, 
x..x,B41,A42,x..x. 

The first SAR-PDU to be completed with valid octets is number 15. 

2) Operation at the end of the communication 

At the end of the communication, the transmitting interleaver is read out until it gets 
completely empty. Some data of the transmitting interleaver will be transmitted twice, 
which has no action in the receiving interleaver where they will be stored a second time 
in positions that have already been read out, and which will be interpreted as dummy 
positions. 

c) Operation in the receiving end 

The mechanism in the receiving interleaver is the inverse of that of the transmitting 
interleaver, i.e. the writing order is diagonal and the reading order is horizontal. For the 
reading, the rule is the following: when the interleaver has been filled up with 14 
SAR-PDUs, then the reading process is started for the first row. 

d) Delineation of the interleaver 

As the process is continuous .in the interleaver, there is no real start of the interleaver. Only 
the even or odd value of the sequence number is necessary in the receiving CS to know if the 
corresponding SAR-PDU begins respectively with a coefficient numbered 1 or with a 
coefficient numbered 48. 

e) Performance 

Correction capabilities of this method are: 

• one cell loss occurrence in the group of 16 cells; 

• three errored octets in a row of 94 octets. 
The overhead of the method is 6.38%. 
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The processing delay imposed by this method is as follows. 

The following calculation of the processing delay takes into account both the transmitting 
and the receiving ends. Let D be the processing delay corresponding to a horizontal/vertical 
processed interleaver. Due to the diagonal mechanism, for a given row of the interleaver, the 
distribution of the delay is as follows: 

• For the first octet of the interleaver, the delay is approximately null in the transmitter and 
approximately D in the receiver. 

• For the last octet of the interleaver, the delay is approximately D in the transmitter and 
approximately null in the receiver. 

As a result, for a given octet, the total delay is D. Examples of values are given for the total 
processing delay. Processing delays are: 14.7 ms for 384 kbit/s, 3.67 ms for 1536 kbit/s, 
2.93 ms for 1920 kbit/s. 

2.5.2.5 Partially filled cell method for control of SAR-PDU payload assembly delay 
This method defines a CS procedure for partially filling the payload of a SAR-PDU to reduce 
payload assembly delay. The method may be of use with delay-sensitive CBR services. The 
procedure assumes that AAL-user information occupies the leading octets of the payload except for 
octets used for CS overhead (i.e! SDT pointer). The procedure assumes that other active AAL-CS 
functions generating overhead are defined so the receiving AAL-CS knows when the payload 
contains overhead, the number of overhead octets and the position of these octets in the payload. The 
partial fill procedure determines the number and position of AAL-user information octets and 
CS-generated dummy value octets in the remaining payload octets. 

The number of AAL-user information octets in a SAR-PDU payload, N (N<47), must be 
determined from the maximum SAR-PDU payload assembly delay. Given a value for N, the 
procedure for assembling the SAR-PDU payload is: 

If no AAL type 1 CS protocol procedures introduce an overhead into the SAR-PDU payload, 
then the number of AAL-user octets is N and the leading octets in the SAR-PDU payload are 
used for the AAL-user information as shown in Figure 13 a). 

If AAL type 1 CS protocol procedures introduce an overhead of C octets (C < 47) into the 
SAR-PDU payload (i.e. SDT), then the specified SAR-PDU payload octets are reserved for 
the CS overhead. The leading octets of the SAR-PDU payload, except for octets reserved for 
CS overhead, are again used for AAL-user information as shown in Figure 13 b). 
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b) Example of partial fill with AAL-CS overhead 

Figure 13/1.363.1 - Format of partially filled SAR-PDU payload 



Due to the introduction of CS overhead, two possible conditions exist with regard to SAR-PDU 
payload AAL-user information capacity: 

1) If N + C < 47, N octets can be used for AAL-user information. 

2) If N + C > 47, less than N octets can be used for AAL-user information. 

When the CS overhead and number of AAL-user information octets in a SAR-PDU payload never 
exceeds 47 [i.e. condition 1) always applies], the number of AAL-user information octets in 
SAR-PDU payloads is always N and the payload assembly delay is a constant for all SAR-PDUs 
generated. Current CS procedures which may be combined with partial fill, such as SDT, only result 
in SAR-PDU payloads satisfying condition 1). When SAR-PDU payloads satisfying condition 2) 
may exist due to the introduction of CS procedures where N + C > 47, further study would be 
required. 

If the number of SAR-PDU payload octets reserved for CS overhead and AAL-user information is 
less than 47, then the remaining payload octets assume a dummy value generated by the AAL-CS 
(see Note). At the receiving AAL entity, the CS shall not pass the payload octets with dummy values 
to the AAL-user. 

NOTE - The value of the SAR-PDU dummy octets generated by the AAL-CS for the control of payload 
assembly delay is to be specified. 

ANNEX A 
Alphabetical list of abbreviations 

AAL ATM Adaptation Layer 

AAL-PCI AAL Protocol Control Information 

AAL-PDU AAL Protocol Data Unit 

AAL-SDU AAL Service Data Unit 

ATM-SDU ATM Service Data Unit 

AUU ATM-User-to-ATM-User 
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CAM Cell Arrival Monitoring 

CBR Constant Bit Rate 

CDV Cell Delay Variation 

CLP Cell Loss Priority 

CRC Cyclic Redundancy Check 

CS Convergence Sublayer 

CS-PDU CS Protocol Data Unit 

CSI Convergence Sublayer Indication 

FEC Forward Error Correction 

FIFO First-In First-Out 

MPEG Moving Picture Experts Group 

OAM Operation and Maintenance 

PDH Plesiochronous Digital Hierarchy 

RS Reed-Solomon 

RTS Residual Time Stamp 

SAP Service Access Point 

S AR Segmentation and Reassembly sublayer 

SAR-PDU SAR Protocol Data Unit 

SAR-SDU SAR Service Data Unit 

SDH Synchronous Digital Hierarchy 

SDT Structure Data Transfer 

SN Sequence Number 

SNP Sequence Number Protection 

SRTS Synchronous Residual Time Stamp 

VBR Variable Bit Rate 



ANNEX B 
Data unit naming convention 



The figure is to indicate the naming of the AAL data units only. It is not implied that all fields are 
present in all cases. See Annex A for abbreviations. 
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Figure B.1/L363.1 - Data unit naming convention 



ANNEX C 

Encoding and information transfer principles 



C.l Cell payload field encoding 

The encoding of the 384-bit/48-octet payload is defined relative to the cell header using the 
following conventions. 

1) Bit positions in the 384-bit cell payload are located with respect to the cell header: 

• The first bit position in the cell payload is adjacent to the cell header and designated 
payload bit "1". 

• The last bit position in the cell payload is designated payload bit "384". 

2) Octet positions in the 48-octet cell payload are located with respect to the cell header: 

• The first octet position in the cell payload is adjacent to the cell header (i.e. payload bit 
positions 1-8) and designated payload octet "1". 
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• The last octet position in the cell payload (i.e. payload bit positions 377-384) is 
designated payload octet "48". 

3) Bits within a specified payload octet are oriented with respect to the cell header: 

• The most significant bit (i.e. 2 7 ) position is the octet bit position nearest to the cell 
header which is designated octet bit "8". 

• The least significant bit position (i.e. 2°) is the octet bit position furthest from the cell 
header which is designated octet bit "1". 

Figure C.l illustrates the encoding principles. 

The orientation of bits/octets within a cell payload field/subfield follows the convention for orienting 
bits in a payload octet when the cell payload field/subfield has multiple bits and the payload octet 
convention for orienting octets when the cell payload field/subfield has multiple octets: 

The most significant bit position of a cell payload field/subfield is the bit position nearest to 
the cell header and the least significant bit position of a cell payload field/subfield is the bit 
position furthest from the cell header when describing bit orientation. 
The first octet position of the field/subfield is the octet position nearest to the cell header and 
the last octet position of the field/subfield is the octet furthest from the cell header when 
describing octet orientation. 

C.2 AAL user information transfer 

The writing and reading of AAL-user information into and out of cell payloads by the AAL adopts a 
First-In First-Out (FIFO) convention. This convention coupled with the assumption of sequential 
integrity of information transfer by the ATM layer (i.e. cell sequence integrity) preserves the 
sequential integrity of AAL-user information. 

1) At the sending AAL-entity during cell payload assembly 

The first bit (octet) received from the AAL user for the cell payload is assigned to the 
payload bit (octet) position nearest the cell header reserved for AAL-user information. The 
other bits (octets) received from the AAL user are sequentially assigned to payload bit (octet) 
positions in ascending order until the highest payload bit (octet) position reserved for AAL- 
user information is filled. 

2) At the receiving AAL-entity during cell payload disassembly 

The bits (octets) of AAL-user information in a cell payload are passed to the AAL user 
sequentially in ascending order beginning with the bit (octet) of AAL-user information 
occupying the payload bit (octet) position nearest the cell header. 



Recommendation 1.363.1 (08/96) 27 



Cell pay load bit/octet positions 





4 






























► 


Cell 
header 


1 


2 


3 


4 


5 


6 


7 


8 



-Octet 48- 



377 



378 



379 



380 



381 



382 



383 



384 



bit 


bit 


bit 


bit 


bit 


bit 


bit 


bit 


8 


7 


6 


5 


4 


3 


2 


1 


2 7 


2 6 


2 5 


2 4 


2 3 


2 2 


2 1 


2° 



T1 306770-95 



Bit orientation within an octet 



Figure C.1/L363.1 - Encoding principles 



APPENDIX I 
Functional model and SDL of AAL type 1 



LI 



Functional model of the SAR 




Figure 1. 1/1.363.1 - Functional model of the SAR at the transmitting side 
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Figure I.2/I.363.1 - Functional model of the SAR at the receiving side 
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Figure I.3/L363.1 - SDL of SAR transmitter 
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Figure I.4/I.363.1 - SDL of SAR receiver 
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APPENDIX n 

Informative and example parameters for AAL type 1 protocol 

In order to facilitate further work on a detailed procedure description for a specific higher layer, this 
appendix gives informative and example parameters, i.e. a set of procedures and options, for some 
specific AAL type 1 services. It should be noted that: 

1) the following description is intended to give informative material only; 

2) not all AAL type 1 services are listed; 

3) the use of parameters other than those described is not precluded; and 

4) use of certain parameters is not illustrated. 

Further detailed parameters can be defined, where necessary and appropriate, with respect to a 
specific higher layer in an associated Recommendation. 

II. 1 Circuit transport 

II. 1.1 Transport of digital channel supported by 64 kbit/s- based ISDN 

a) Transport of 64 kbit/s channel 
CBR rate at AAL service boundary: 64 kbit/s 
Source clock frequency recovery: Synchronous 
Error correction method: Not used 
Error status indication at the receiver: Not used 
Pointer: Not used 
Partially fill cell method: Not used 

b) Transport of 384 > 1536 or 1920 kbit/s channel 

CBR rate at AAL service boundary: 384, 1536 or 1920 kbit/s 

Source clock frequency recovery: Synchronous 

Error correction method: Not used 

Error status indication at the receiver: Not used 

Pointer: Used (Note) 

Partially fill cell method: Not used 

NOTE - Pointer is mandatory to support 8 kHz integrity for 64 kbit/s-based ISDN services at rates 
greater than 64 kbit/s, i.e. a demarcation of 6 (384 kbit/s), 24 (1536 kbit/s) and 30 (1920 kbit/s) 
octets per 125 (is. 

II.1.2 Transport of G.702 PDH circuit 

For this example, it is important to distinguish the clock operation mode at the AAL service 
boundary, i.e. service clock, with respect to a network clock. Asynchronous circuit transport provides 
transport of signals from CBR sources whose clocks are not frequency-locked to a network clock. 
Synchronous circuit transport provides transport of signals from CBR sources whose clocks are 
frequency-locked to a network clock. Whether it is synchronous or asynchronous will depend on the 
service provided by the specific network. 
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• 



a) 



b) 



Synchronous circuit transport 

CBR rate at AAL service boundary: (Note 1) 
Source clock frequency recovery: Synchronous 
Error correction method: Not used 

Error status indication at the receiver: Not used 
Pointer: Not used 

Partially fill cell method: Not used 

NOTE 1 - Example bit rates are 1.544, 2.048, 6.312, 8.448, 44.736 and 34.368 Mbit/s as defined in 
Recommendation G.702. 



Asynchronous circuit transport 

CBR rate at AAL service boundary: 
Source clock frequency recovery: 
Error correction method: 
Error status indication at the receiver 
Pointer: 

Partially fill cell method: 



(Note 2) 

Asynchronous (Note 3) 
Not used 
Not used 
Not used 



Not used 

NOTE 2 - Example bit rates are 1.544, 2.048, 6.312, 8.448, 44.736 and 34.368 Mbit/s as defined in 
Recommendation G.702. 

NOTE 3 - There are two clock recovery methods for asynchronous circuit transport, adaptive clock 
or SRTS method. The adaptive clock method supports circuit transport application where control of 
wander can be relaxed (see 2.5.2.2.1). The SRTS method supports circuit transport application 
where control of jitter and wander is necessary (see 2.5.2.2.2). The need to control wander is not 
determined solely by the applications supported, but also by the points of AAL connection 
termination (i.e. CPE to CPE termination, network to network termination, CPE to network 
termination). 

11.13 Transport of G.709 SDH circuit 

This example illustrates circuit transport of G.709 SDH signals. 
Transport ofTU-U, TU-12 or TU-2 
CBR rate at AAL service boundary: 
Source clock frequency recovery: 
Error correction method: 
Error status indication at the receiver: 
Pointer: 

Partially fill cell method: 



1728, 2304 or 6912kbit/s 

Synchronous 

Not used 

Not used 

Used (Note) 

Not used 



NOTE - Pointer is mandatory to indicate VI byte of TU-1 1, TU-12 or TU-2. 



IL2 Video signal transport 

a) Distributive television services 

This example illustrates transport of distributive television signals encoded by using MPEG2 
with a constant bit rate, as described in Recommendation J.82. 

• CBR rate at AAL service boundary: Depending on MPEG2 parameters 

• Source clock frequency recovery: Asynchronous (Note 1) 
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b) 



c) 



• Error correction method: Used (procedure of 2.5.2.4.2) (Note 2) 

• Error status indication at the receiver: Used 

• Pointer: Not used 

• Partially fill cell method: Not used 
NOTE 1 - The adaptive clock method is used (see 2.5.2.2.1). 

NOTE 2 - This method can perform correction of, i.e. 4 cell losses within 128 cells. Detailed 
performances are given in 2.5.2.4.2. 

Conversational services of bit rates higher than primary rates 

This example illustrates transport of interactive video signals for, i.e. videotelephony and 
conference application, as specified in Recommendation H.310. 



CBR rate at AAL service boundary: 
Source clock frequency recovery: 

Error correction method: 

Error status indication at the receiver: 
Pointer: 

Partially fill cell method: 



Depending on H.310 parameters 

Synchronous/Asynchronous per 
Recommendation H.310 

Used or not used per Recommendation H.310 
(Note 3) 

Used or not used per Recommendation H.3 10 
Not used 
Not used 



NOTE 3 - No error correction method is used in an error free environment or a situation where a 
higher layer does not need correction of cell losses and/or bit errors. Error correction methods as 
described in 2.5.2.4 may be used in an error prone environment or a situation where a higher layer 
needs correction of cell losses and/or bit errors. 

Conversational services ofpx64 kbit/s signals 

This example illustrates transport of interactive video signals of the p x 64 videotelephony 
and videoconference applications as specified in Recommendation H.320. 



. 4- 



CBR rate at AAL service boundary: 

Source clock frequency recovery: 

Error correction method: 

Error status indication at the receiver: 

Pointer: 

Partially fill cell method: 



384, 1536 or 1920 kbit/s (Note 4) 

Synchronous 

Used or not used (Note 3) 

Not used 

Not used (Note 5) 



Not used 

NOTE 4 - The example bit rates are those supported in the 64 kbit/s-based ISDN by using HO, HI 1, 
H12, respectively. 

NOTE 5 - Recommendation H.221, as a part of Recommendation H.320, provides bit-by-bit 
synchronization; hence, it does not need the support of 8 kHz integrity. 

II.3 Voiceband signal transport 

This example illustrates transport of 64 kbit/s A-law or |i-law coded Recommendation G.7H signals. 

• CBR rate at AAL service boundary: 64 kbit/s 

• Source clock frequency recovery: Synchronous 

• Error correction method: Not used 

• Error status indication at the receiver: Not used 



34 Recommendation 1.363.1 (08/96) 




• Pointer: Not used 

Partially fill cell method: Not used 

NOTE - Care should be taken to minimize delay at the receiver for alleviating echo performance problems. 
See 2.5. 1.3 for a detailed description. 

APPENDIX IH 

Informative and example operations for handling of lost/misinserted cells 
and for maintaining bit count integrity 



111.1 Introduction 

This appendix provides informative examples for handling lost/misinserted cells and for maintaining 
bit count integrity. The material in this appendix is informative and should not be construed as 
mandatory implementation requirements. 

Subclause ffl.2 gives two algorithms for SN processing. Both algorithms detect lost cells. In addition, 
one algorithm detects misinserted cells while the other algorithm imposes no inherent processing 
delay and is thus suitable for delay-sensitive applications. Both algorithms have to be supplemented 
by mechanisms to maintain bit-count integrity for the replacement of lost information, i.e. via 
dummy cells. 

Subclause m.3 provides mechanisms that maintain bit-count integrity and have a limited ability to 
detect lost/misinserted cells. They do not impose an inherent delay exceeding the nominal CDV. In 
order to be able to use these mechanisms without any supplementary SN processing, the CDV must 
be small compared with the minimum cell inter-arrival time. For the transport of delay sensitive 
signals such as 64 kbit/s voiceband signals, the use of these SN processing algorithms must not 
introduce additional delay . 

Some AAL services, such as voiceband signal transport (see 2.5.1.3), must accommodate a sudden 
increase or decrease in the nominal cell transfer delay which might result, for example, from a 
protection switching event. The handling of such a change in cell transfer delay is possible by 
enhancing the mechanisms described in this appendix but is not addressed. 

111.2 Sequence number processing 
III.2.1 General 

Examples of algorithms for the processing of the Sequence Number in AAL type 1 are given. Two 
different algorithms are described: a robust algorithm, in which the decision to accept a cell is taken 
after the arrival of the next cell; and a fast algorithm, in which the decision to accept the cell is taken 
immediately after arrival of the cell. Potential problems due to the delay in waiting for the next cell, 
which arise with low bit rate services, are avoided by the fast SN algorithm. On the other hand, the 
robust algorithm is able to distinguish between lost and misinserted cells and thus may be more 
useful for applications which are sensitive to misinserted cells. 

IIL2.2 Indications from the SAR sublayer 

The SAR sublayer provides the following inputs to the CS, concerning the SN field: 

a) the value of the SC (3 bits); 

b) the value of the CS indication (CSI) in the SN field ( 1 bit); 

c) the check status (valid or invalid) of the SN field. 
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Only indications a) and c) are used by the algorithms to determine lost/misinserted cells. 

111.2.3 Capabilities of the algorithm 

Both algorithms have the following capabilities: 

• detect a maximum of 6 consecutive lost cells; 

• do not unnecessarily discard a cell with an invalid SN field. 

In addition, the robust SN algorithm identifies and discards a single misinserted cell. 

111. 2.4 The algorithms 

A simplified comparison of the two algorithms is given in Figure EH. 1. The algorithms are described 
by a common state machine with five states, as shown in Figure EQ.2. An evolution in the state 
machine is indicated by an arc, on which there are two distinct values represented. The first value 
refers to the event that originates the evolution in the state machine, and the second value refers to an 
action to be taken as a result of the event. 

III.2.4.1 Robust SN algorithm 

A decision in this algorithm is taken after the analysis of two consecutive SNs. This means that when 
a cell is received, it is stored, waiting for the next one before it is eventually passed to the final 
destination. In the state machine, the action always refers to the stored cell. 

A valid SN is defined as an SN which has no detected errors or had an error that was corrected. 

The details of the algorithm are the following: 

a) START 

It is the initial state. It remains in this state discarding the cells until there is a valid SN. 

b) OUT OF SYNC 

In this state, the sequence counting is not synchronized yet. It waits for an SC that is in 
sequence with the previous one. When it occurs, the stored cell is accepted by the system. If 
a cell with an invalid SN is received, the system returns to START and the stored cell is 
discarded; 

c) SYNC 

In this state, the sequence counting is considered to be synchronized: 

• If the SC is in sequence with the previous one, it remains in this state and the stored cell 
is accepted. 

• If the SN is invalid, it goes to INVALID, but the stored cell is accepted. 

• If the SC is not in sequence with the previous one, it goes to OUT OF SEQUENCE, 
accepting the stored cell. 

d) INVALID 

In this state, the system shall take a decision on the stored cell with the invalid SN, when it 
receives the next cell: 

• If the SN is again invalid, the system returns to START and the stored cell is discarded. 

• If the SN is valid and the SC is in sequence with the last cell received with a valid SN, 
the system returns to SYNC, but the stored cell is considered to be misinserted and it is 
discarded. 

• If the SN is valid but the SC has a value exceeding by two the SC of the last cell 
received with a valid SN, it is assumed that although there was an invalid SN the stored 
cell is in sequence and therefore it is accepted. It returns to SYNC. 
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• if the SN is valid but is not in any of the previous situations, it discards the stored cell 
and goes to OUT OF SYNC. 

e) OUT OF SEQUENCE 

In this state the following actions are taken when a cell arrives: 

• If the SN is invalid, it discards the stored cell and it goes to START. 

• If the SN is valid and the SC is in sequence with the last cell received prior to the stored 
one, the system returns to SYNC, but the stored cell is considered to be misinserted and 
is discarded. 

• If the SN is valid and the SC is in sequence with the SC of the stored cell, the system 
assumes that cells were lost; it inserts a number of dummy cells identical to the number 
of lost cells, accepts the stored cell and returns to SYNC. 

• If the SN is valid and the SC has a value exceeding by two the SC of the last cell 
received prior to the stored cell, the system assumes that the stored cell was in sequence 
(i.e. the SN error protection mechanism failed) and therefore it accepts the stored cell 
and returns to SYNC. 

• If the SN is valid but is not in any of the two previous situations, it discards the stored 
cell and goes to OUT OF SYNC. 

III.2.4.2 Fast SN algorithm 

A decision in this algorithm is taken immediately after the analysis of the received cell. This means 
that when a cell is received, the SN is immediately evaluated and the cell is eventually passed to the 
final destination. In the state machine, the action always refers to the last cell received. 
A valid SN is defined as an SN which has no detected errors or it had an error that was corrected. 
The details of the algorithm are the following: 

a) START 

It is the initial state. It remains in this state discarding the cells until there is a valid SN. 

b) OUT OF SYNC 

In this state, the sequence counting is not synchronized yet. It waits for an SC that is in 
sequence with the previous one. When it occurs, the received cell is accepted by the system. 
If a cell with an invalid SN is received, the system returns to START and the received cell is 
discarded. 

c) SYNC 

In this state, the sequence counting is considered to be synchronized: 

• If the SC is in sequence with the previous one it remains in this state and the received 
cell is accepted. 

• If the SN is invalid, it goes to INVALID, but the received cell is accepted. 

• If the SC is not in sequence with the previous one, it goes to OUT OF SEQUENCE, 
accepting the received cell. 

d) INVALID 

In this state, the system shall take the following decisions on the received cell: 
. If the SN is again invalid, the system returns to START and the received cell is 
discarded. 
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• If the SN is valid and the SC is in sequence with the last cell received with a valid SN, 
the system returns to SYNC, but the received cell is discarded to keep bit-count integrity 
because the previous cell is considered to be misinserted but is already sent. 

• If the SN is valid and the SC has a value exceeding by two the SC of the last cell 
received with a valid SN, it is assumed that although there was an invalid SN, the 
received cell is in sequence and therefore it is accepted. It returns to SYNC. 

• If the SN is valid but is not in any of the previous situations, it discards the received cell 
and goes to OUT OF SYNC. 

e) OUT OF SEQUENCE 

In this state the following actions are taken when a cell arrives: 

• If the SN is invalid, it discards the received cell and it goes to START. 

• If the SN is valid and the SC is in sequence with the last cell received with a valid SN, 
the system returns to SYNC, but the received cell is considered to be misinserted and is 
discarded to keep bit-count integrity because the previous cell is considered to be 
misinserted but is already sent. 

• If the SN is valid and the SC is in sequence with the SC of the previous cell, the system 
assumes that cells were lost; it inserts a number of dummy cells identical to the number 
of lost cells, accepts the received cell and returns to SYNC. 

• If the SN is valid and the SC has a value exceeding by two the SC value of the last cell 
received in sequence (i.e. the SN error protection mechanism failed), the system assumes 
that the received cell was in sequence and therefore it accepts the received cell and 
returns to SYNC. 

• If the SN is valid but is not in any of the two previous situations, it discards the received 
cell and goes to OUT OF SYNC. 
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Figure IIL1/L363.1 - Differences between robust and fast SN algorithms concerning 
the actions performed at the state machine 
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Figure IIL2/L363.1 - Informative and example algorithm state machine 



III.3 Mechanisms to maintain bit-count integrity and basic handling of lost/misinserted cells 

This subclause briefly describes two mechanisms: Cell Arrival Monitoring (CAM) and buffer-fill 
level monitoring. These algorithms provide some capability to detect lost and misinserted cells. They 
maintain bit-count integrity and impose a delay, in conveying user information across the AAL 
receiver, which is approximately equal to the CDV. They can be supplemented by either one of the 
SN processing algorithms described previously in this appendix. For such jomt operation, if an 
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expected cell arrives during the course of delivering dummy bits/octets to the AAL user, appropriate 
bits/octets from this cell can be used, subsequently resulting in less loss of information. 

For specific delay sensitive applications such as the transport of 64 kbit/s voiceband signals, these 
mechanisms may be used without any SN algorithms or with the fast SN algorithm described above. 
For specific delay-sensitive applications, joint operation with other algorithms - which, like the fast 
SN algorithm, do not introduce additional delay - is also possible. Such joint operation may be 
useful for connections for which it is difficult to establish a tight CDV bound. 

IIL3.1 Buffer-fill level monitoring 

The buffer associated with the individual connection has to be monitored. In the case of buffer 
underflow, which can, for example be the result of cell loss or cell discard, dummy bits/octets are 
inserted depending on the specific application. In the case of buffer overflow, i.e. a defined level of 
buffer fill is exceeded, bits/octets have to be discarded. 

III.3.2 Cell Arrival Monitoring 

The AAL receiver may use a CAM technique. A time window of width determined by the nominal 
CDV is established around the expected arrival instant of the next cell. The first cell that arrives 
within the window is accepted. If no cell arrives within the window, dummy bits/octets are used 
upon expiration of the window. 
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